DragonFly kernel List (threaded) for 2003-12
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@xxxxxxxxxxxxxxxxx Senior Research Scientist, McAfee Research