FreeBSD 6.2/Quarterly report

[nslay]

FreeBSD 6.2 was released on Monday (1/15) ... its very nice. (EDIT, I went and checked my inbox, it was actually Monday)
So some of the updates include:
Fixes and improvements to iwi
- iwi previously had serious locking problems, probably due to FreeBSD 5.x/6.x transition to SMP from GIANT.  iwi additionally uses the new firmware(4) interface to load firmware to hardware.
new security event auditing feature (a component of TrustedBSD)
- As I understand it, this removes power from root in respects to logging and auditting and allows applications to tap into security-related events also.  This way, even root can't change logged events...the power rests with the kernel.
Again more locking problems fixed in devfs
- devfs previously had deadlocking problems
csup, a new cvsup!
- FreeBSD now has its own cvsup client and it lives in the FreeBSD base (not like cvsup which must be installed via ports/packages).
freebsd-update
- This is an application to do binary-only updates...apparently it allows one to update FreeBSD in minutes (instead of having to buildworld and kernel which can take hours).

There were a few other things...you can check out the release notes here:
http://www.freebsd.org/releases/6.2R/relnotes.html

Additionally, today I got a copy of the FreeBSD Project's quarterly report in FreeBSD-announce mailing list!
One particular article caught my eyes....ZFS is apparently functional in all respects except ACLs...I wonder if 6.3 will have ZFS as an experimental feature, I'm very eager to try it out (and ditch FFS!).

You can see a copy of the quarterly report here:
http://www.freebsd.org/news/status/report-oct-2006-dec-2006.html

[Newby]

I'll wait until ZFS is 100% functional before I upgrade my router. My mom's method of pulling the power cord has left me with no choice but to fsck it multiple times on occasion.

[iago]

- As I understand it, this removes power from root in respects to logging and auditting and allows applications to tap into security-related events also.  This way, even root can't change logged events...the power rests with the kernel.

Can't root, like, modify the kernel?  ie, load a kernel module that looks after that?

[nslay]

- As I understand it, this removes power from root in respects to logging and auditting and allows applications to tap into security-related events also.  This way, even root can't change logged events...the power rests with the kernel.

Can't root, like, modify the kernel?  ie, load a kernel module that looks after that?

What do you mean?  Looks after what?
If you want more information on FreeBSD security event auditing, you should read this interview wirh Robert Watson regarding security event auditing:
http://www.securityfocus.com/columnists/422

Here is a brief description:

Robert Watson: Security Event Auditing refers to the fine-grained logging of security events in the system, and is basic security functionality long overdue in open source operating systems. There are three things that differentiate auditing from traditional OS logging facilities such as syslog: security/reliability, granularity, and configurability. Security standards require that audit trails be both secure and reliable--for example, that log records only be accepted from trusted sources, and that they be delivered with reliability guarantees to the audit log. They require the ability to track very fine-grained security events, including files accesses, network events, and so on. Finally, the standards require that this be configurable so that the rate and content of logging can be usefully managed. UNIX syslog does none of these facilities well, if at all, as it is a general purpose log mechanism.