With rbac the root user can delegate commands to certain users. In other words, a small part of root power can be given to regular users. On the system i am to setup i want to give the power of shutdown to a non-root user. Once setup, the user can su to the custom role and shut the system down.

First, create the role.

anouk:/ # roleadd -u 1000 -g 10 -d /export/home/pseudo -m pseudo

anouk:/ # passwd pseudo
New Password:
Re-enter new Password:
passwd: password successfully changed for pseudo

anouk:/ # pwconv (syncs /etc/shadow to /etc/passwd)

anouk:/ # cat /etc/passwd | grep pseudo
pseudo:x:1000:10::/export/home/pseudo:/bin/pfsh (pfsh = profile shell - bourne shell)

Create the profile with comments about its ability:

anouk:/ # echo “Shutdown:::Shutdown the system” >> /etc/security/prof_attr

Add the profile to the role:

anouk:/ # rolemod -P “Shutdown” pseudo

The role has to be assigned to an account:

anouk:/ # usermod -R pseudo mglas

Assign commands to the profile:

anouk:/ # echo Shutdown:suser:cmd:::/usr/sbin/shutdown:uid=0 >> /etc/security/exec_attr

anouk:/ # roles mglas
pseudo

anouk:/ # profiles pseudo
Shutdown
Basic Solaris User
All

So now user mglas has been assigned the role ‘pseudo’, so now this user can su - to the role and shut down the system.

anouk:~ $ su - pseudo
Password:

$ /usr/ucb/whoami
pseudo

$ /usr/bin/who am i
mglas      pts/2        Jan 31 16:30    (203.48.45.198)

$ /usr/sbin/shutdown -i 6 -g 0

Shutdown started.    Thu Jan 31 16:31:46 EST 2008

Do you want to continue? (y or n):

Previously i setup auditing (see this post), but used only praudit for very basic viewing of audit files. There is another, more powerful command known as auditreduce. As always, use the man pages but here are the most common uses of this command.

Of course first up it will not work on the currently active audit file, so use the audit -n command to roll that over.

An audit log file looks like this: 20071218114258.20071218143001.amsterdam

The date goes yyyymmddhhmm.yyyymmddhhmm.hostname. The first field is the log start time and 2nd the end time. An unterminated logfile looks like: 20071218143001.not_terminated.amsterdam. The audit -n command would roll that over to 20071218143001.20071219010332.amsterdam which also allows it to be read.

To just list one of these files use: # praudit 20071218143001.20071219010332.amsterdam. This can be made more readable by using the -l flag which converts it to ascii and print 1 record per line. # praudit -l 20071218143001.20071219010332.amsterdam

To not bother with filenames the auditreduce command can be used. # auditreduce | praudit -l will show ALL logged events. Fortunately auditreduce allows us to be more specific.

# auditreduce -c lo | praudit -l will show ALL login/logout events.

# auditreduce -u <username> -c lo | praudit -l will show ALL logins/logouts for the specified user.

# auditreduce -u <username> -a 20071216 -c lo | praudit will show ALL logins/logouts from 16/12/07 for specified user.

# auditreduce -u <username> -a 20071101 -b +31d -c lo | praudit will show ALL logins/logouts for November 07 for specified user.

So i created a quick script to collect this information and log it for me. Every day it will log the last 2 days of all user logins. The requirement for this script is the coreutils package and the directory /var/audit/log to be created. Oh, to save space this script will only work in December.

#!/bin/bash
audit -n
DATE=`/usr/local/bin/date -d “-2 day”`
month=`echo $DATE | awk ‘{print $2}’`
case $month in
Dec) DATE=”$DATE 12″ ;;
esac
datetocheck=`echo $DATE | awk ‘{print $6$7$3}’`
DATE=`date ‘+%y-%m-%d’`
auditreduce -a $datetocheck -c lo | praudit -l | grep login | awk ‘{print $3 $4 $5}’ >> /var/audit/log/log.$DATE

See: praudit, auditreduce, bsmconv, auditd

A friend of mine convinced me to learn more about security in Solaris 10. I thought i would start with auditing, commonly known as bsm auditing. Audits are written to binary files and originate from logins and the kernel. Levels of logging need to be determined wisely as disk space can be used up very quickly.

First step to enabling auditing is to run the /etc/security/bsmconv script. This creates a config file /etc/security/audit_startup and moves /etc/vold.conf to /etc/security/spool/vold.state with the intention to block users from inserting insecure files or binaries. For more information do a man on bsmconv.

An entry is added to /etc/system:

set c2audit:audit_load = 1 which enables auditing on the kernel and on the system.

At this stage a reboot is required. After reboot perform a ps -ef on auditd to confirm this daemon is running:

amsterdam:/ # ps -ef | grep auditd
root 443 1 0 11:19:45 ? 0:00 /usr/sbin/auditd

All configuration files reside in /etc/security

amsterdam:/ # cd /etc/security/
amsterdam:/etc/security # ls
audit audit_record_attr bsmconv device_maps lib
audit_class audit_startup bsmunconv device_policy policy.conf
audit_control audit_user crypt.conf exec_attr priv_names
audit_data audit_warn dev extra_privs prof_attr
audit_event auth_attr device_allocate kmfpolicy.xml spool

There are man pages for all these config files. For now i am only interested in the audit_user and audit_class files. The audit_class file lists the events that can be audited.

amsterdam:/etc/security # cat audit_class
…. snip
0×00000000:no:invalid class
0×00000001:fr:file read
0×00000002:fw:file write
0×00000004:fa:file attribute access
0×00000008:fm:file attribute modify
0×00000010:fc:file create
0×00000020:fd:file delete
0×00000040:cl:file close
0×00000100:nt:network
0×00000200:ip:ipc
0×00000400:na:non-attribute
0×00001000:lo:login or logout
0×00004000:ap:application
0×00010000:ss:change system state
0×00020000:as:system-wide administration
0×00040000:ua:user administration
0×00070000:am:administrative (meta-class)
0×00080000:aa:audit utilization
0×000f0000:ad:old administrative (meta-class)
0×00100000:ps:process start/stop
0×00200000:pm:process modify
0×00300000:pc:process (meta-class)
0×00400000:xp:X - privileged/administrative operations
0×00800000:xc:X - object create/destroy
0×01000000:xs:X - operations that always silently fail, if bad
0×01c00000:xx:X - all X events (meta-class)
0×20000000:io:ioctl
0×40000000:ex:exec
0×80000000:ot:other
0xffffffff:all:all classes (meta-class)

amsterdam:/etc/security # cat audit_user
… snip
root:lo:no

So at this stage only root logins/logouts are logged. I will amend this file to include all users with the lo flag to record when my users log in. Then i will setup accounting to receive daily reports. If i see any irregular behavior i may then increase the level of logging to determine if something fishy is going on.

To view the binary log files two commands are used. praudit and auditreduce - in conjunction with various flags of course. Logs are stored in /var/audit.

amsterdam:/var/audit # ls

20071213004722.not_terminated.amsterdam

The numbers represent the date. So this file was last accessed on 13/12/2007 12:47:22. We will first have to stop writing to this file:

amsterdam:/var/audit # audit -n
amsterdam:/var/audit # ls

20071213004722.20071213040133.amsterdam 20071213040133.not_terminated.amsterdam

The previous session is closed and can be read using the praudit command.

amsterdam:/var/audit # praudit 20071213004722.20071213040133.amsterdam

And the contents of the file appear.

If you want to see every command issued by your users a line in the /etc/security/audit_user would look like:

username:lo,ex

But this will result in large log files. A balanced approach needs to be found to logging and trawling thru log files. Next i will look at setting up accounting so a daily/weekly/monthly report will be emailed to assist with the trawling thru these log files. I also will take a closer look at the viewing of audit log files with auditreduce command.

EDIT: This post details using praudit and auditreduce to view binary audit log files.