Re: TrustedBSD...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I agree and disagree both in principle and practice :-).  Actually, I
:think you'll find that if you dig a little deeper, the placement of MAC
:Framework entry points is done exactly on the philosophy you describe.  In
:order to prevent race conditions, you have to perform access control
:checks on the actual objects, not the names provided in system calls.  We
:place our checks at the front ends of various subsystems: i.e., the top
:layer of VFS, the top layer of the process signalling pieces, etc.  This
:is the point where the name has been resolved to the object, and the
:correct locks are held to make sure you can perform a consistent check. In
:a traditional UNIX kernel, you cannot do this safely at the system call
:layer using wrappers, because that involves multiple lookups, which can be
:raced (time of check, time of use).
:...
:Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
:robert@xxxxxxxxxxxxxxxxx      Senior Research Scientist, McAfee Research

    I'm about half way through 'fixing' the namespace handling 
    (namei/vfscache).  I had to set it aside a month ago just to get
    the ball rolling on other things and I have to rethink some of the
    mechanisms (guarenteeing a clean cache hierarchy all the way to root
    is difficult due to the file-handle-to-vnode routines that NFS uses),
    but it is still in the queue :-)

    The idea is to implement a namespace locking mechanism that is totally
    separate from the vnode locking mechanism we currently have.  This would
    make it possible to gain soft-locks on namespace and meta-data that
    could safely be held for long periods of time without interfering with
    vnode operations.

    So, for example, one would be able to reserve the final path component
    in an O_CREAT open() without having to leave the directory vnode locked
    through the operation.  Another process attempting to create the target
    file would stall until the reservation is released.  Or, as another
    example, ownership and other related authentication data could be
    soft-locked without interfering with the file vnode or governing directory
    vnode locks.

    But even then one still has the duel-lookup issue.  With syscall messages
    it's a bit easier to fix then with direct system calls because all of the
    auxillary data can be embedded in the kernel's copy of the syscall
    message itself (a mechanism which already exists in DFly but is not yet
    widely used), which means that a filter or other security mechanism can
    resolve the required information just once, store it in the syscall
    message, set a flag, and the downstream syscall handler will not try to
    resolve it again.

    That's a tad messy but not nearly as messy as it would be to implement
    it in a direct syscall model.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>