Auditing shell commands
By Darren Moffat-Oracle on Sep 05, 2008
Via OSnews I came across a IBM article on KornShell 93 command auditing. Even before reading the article I viewed it with some caution. Why ? because you can't actually trust the shell to do what I know as auditing. Auditing of command execution "inside" the shell isn't sufficiently security and trustworthy, it has to be done in the TCB (Trusted Computing Base) of the OS (usually the kernel and some core system services in userland). The TCB is only place that really knows everything that was executed and the only place that really knows the credentials of the executing user.
All the user has to do to by pass shell level "auditing" is start a different shell, this is harder though if a restricted shell is being used. The other thing that concerns me with a shell level implementation is that when writing the log to a local file it needs to be able to be written to by the unprivileged user because ksh wouldn't be (well I hope not) installed setuid. This makes it considerably less trustworthy as the user can easily modify the log to remove or alter things.
Now compare this to the in kernel OpenSolaris/Solaris audit trail (that has been a part of SunOS in excess of 15 years); it is stored read/write only by root and the audit records are generated in kernel. Not only are the records generated in kernel the identity of the original logged in user (we call this the audit uid) is preserved even over multiple su(1M) commands or calls to setreuid() - something shell level "auditing" can't do.
The Solaris in kernel auditing does much more than just audit exec(2) calls and provides an audit trail for all security sensitive (ie any time privilege or access descisions are made) operations. In addition to kernel provided audit records privileged programs (those running with proc_audit on Solaris 10 or later or those running as uid 0 on earlier releases) such as the SMF service daemons or the SMC admin system can also write higher level "application specific" audit records, eg sevice start, user added/modified.
To configure OpenSolaris to log just the commands that users run is relatively simple. First turn on auditing by running /etc/security/bsmconv. Then in /etc/security/audit_control add "ex" to the flags line. If you want command arguments as well as the command names then add "/usr/sbin/auditconfig -setpolicy +argv" to /etc/security/audit_startup. You can also enable logging of the environment variables by adding +arge. This will log command execution for all users.
If instead of all users you only want to audit a subset then use the /etc/security/audit_user file instead (or as well as to change the policy for some users), eg to audit just bob add "bob:ex:" to /etc/security/audit_user. The audit_user information can also be stored in all supported nameservices (files, NIS(YP), NIS+, LDAP) to provide a domain wide audit policy.
The audit trail produced by the kernel is passed to the userland auditd to write. Starting with Solaris 10 auditd uses plugins to write the trail (prior to Solaris 10 it always produced a binary audit trail file). The default is a binary trail but the data can also be sent over syslog in a summary XML-like format: see the audit_syslog(5) man page. A full XML format including DTD and XSTL can be produced out of the binary audit trail using the praudit(1M) command.
Finally the Solaris Audit system is included as part of the security target that helped get the Common Criteria certification of Solaris 10 (and several previous releases) to EAL4+ for CAPP, RBACPP, LSPP. I would not expect that the "auditing" in ksh93 would be sufficiently secure or detailed to met any Common Criteria audit requirements.