TrustedBSD...

[Robert Watson]

On Tue, 9 Dec 2003, Matthew Dillon wrote:

>     I see two ways to implement the filter mechanism:
> 
>     (1) The filter would have to implement the copyin/copyout layer and then
>         call the syscall meat layer.  Any filtered syscalls that don't 
> 	actually have to examine user-supplied data could simply call the
> 	main syscall entry point after acceptance, so it would not be too
> 	messy.  This is easier to do then #(2) but makes the layering of
> 	multiple syscall filters difficult.
> 
>     (2) Do all copyins necessary for filter operations (basically anything
> 	that passes a path) prior to executing the first filter.  Then the
> 	filters need only deal with the data.  Harder but probably the more
> 	effective solution.

I think this will work fine for rules based on subjects and simple
arguments (uids, socket types, addresses, signal numbers), but will still
run into the second class of race conditions I mentioned: performing
checks separate from usage means "things can change" between the check and
the use.  I.e., if you resolve a path twice, it may resolve differently. 
You really want to resolve the path exactly once for check and use, and
this is largely a result of a file system pathname really representing a
compound operation which you'd like to be consistent when executed twice. 
With a VFS based on capabilities and message passing, you could do it,
because the lookup would consist of a series of operations and the names
used by the consumer and producer would be in the same namespace (i.e.,
vnode references represented by ports). 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at xxxxxxxxxxxxxxxxx      Senior Research Scientist, McAfee Research