Friday September 05, 2008
ZFS Crypto Codereview starts today Prelim codereview for the OpenSolaris ZFS Crypto project starts today (Friday 5th September 2008 at 1200 US/Pacific) and is scheduled to end on Friday 3rd October 2008 at 2359 US/Pacific. Comments recieved after this time will still be considered but unless there are serious in nature (data corruption, security issue, regression from existing ZFS) they may have to wait until post onnv-gate integration to be addressed; however every comment will be looked at and assessed on its own merit.
For the rest of the pointers to the review materials and how to send comments see the project codereview page.
( Sep 05 2008, 05:49:46 PM BST ) PermalinkUsing the Mercurial Forest extension for OpenSolaris onnv-gate
Some background
This is really only relevant to those people doing development on the OpenSolaris onnv-gate that are inside Sun, but it since there is nothing private about it I'm posting it publicly so google can find it.
With the transition from Teamware to Mercurial the onnv-gate source code is now held in two separate repositories. The main repository holding the overwhelming majority of the source code, which is opensourced under various licenses but mostly CDDL, is called "onnv-gate" the source code is in the mercurial repository in a subdirectory called usr/src. The much smaller closed source is in a separate repository that is nested inside the "onnv-gate" as the usr/closed subdirectory.
The usr/src part can be built either by using the downloadable (and redistributable) binaries which make up a proto area for the closed source bits, or the usr/closed part can be built from source along with usr/src. If building both from source then the usr/src and usr/closed mercurial repositories must be in sync otherwise there will be a high risk of either build failures or buggy binaries.
The Mercurial forest extension provides a way to make sure that nested repositorys such as onnv and onnv-closed are always pulled/pushed at the same time.Initial gate setup
$ hg clone ssh://onnv.sfbay.sun.com//export/onnv-clone myrepo $ cd myrepo/usr $ hg clone ssh://onnv.sfbay.sun.com//export/onnv-clone/usr/closed
Syncing with onnv-gate
$ cd path/to/myrepo $ hg fpull
You may find this a little slow as it has to traverse the whole workspace looking for nested repositories so it can build the definition of the forest. This can be speeded up using the "fsnap" command to create a snapshot file. Or you can create one by hand, that may look similar to this:
[tree1] root = . revision = tip path.default = ssh://onnv.sfbay.sun.com//export/onnv-clone [tree2] root = usr/closed revision = tip path.default = ssh://onnv.sfbay.sun.com//export/onnv-clone/usr/closed
To use the snapshot file we run fpull like this:
$ hg fpull --snapfile /path/to/mysnapfile
ONNV-gate push rules
The rules for pushing to the onnv-gate when a single set of fixes needs to span the usr/src and usr/closed trees is that usr/closed must be pushed first. This basically means that you should NOT use the forest extension for pushing. However the number of people that this impacts is very small most developers just need an up to date usr/closed for building.
For this reason I'm not showing how to push with the forest extension here.
( Sep 05 2008, 01:18:09 PM BST ) PermalinkAuditing shell commands
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.
The Security Services admin guide has more information on the capabilities of Solaris Audit and information on administration as well as full details of the connect of the audit records.
( Sep 05 2008, 01:08:03 PM BST ) Permalink Comments [1]
This is a personal weblog, I do not speak for my employer.
