Expanding on one point I've made...

"Perry E. Metzger" <perry@piermont.com> writes:
>> can be redirected so they get serviced by the controller process,
>
> I'm not sure we actually need to do this with a controller
> process. That is certainly a model worth playing with (and that is the
> systrace model), and it provides a very general mechanism, but even
> more restricted mechanisms that operated in kernel can do quite a
> lot.

One thing I've had in mind for a while on this is the model BPF
provides -- that is, loading a small virtual machine program into the
kernel to perform a very specialized task. For BPF, it is picking out
packets to hand to userland. For this, it could be systrace (or
analogous) policies. I don't mean to say this is the best or only way
to do such a thing -- just that there are a wide variety of
implementation strategies for the general model that can be considered.

I do not deny that any mechanism that would fix the races in systrace
or related systems could end up touching a lot of the system call
code. However, the security benefits of being able to cage processes
are very, very important. Such mechanisms make it much easier to run
daemons, especially network daemons, with confidence, and there is a
lot of field experience with using systrace to constrain user code as
well. We have a flawed implementation architecture right now, but we
should not throw out the baby with the bathwater.

-- 
Perry E. Metzger		perry@piermont.com