der Mouse <mouse@Rodents.Montreal.QC.CA> writes:
>> I agree that the *implementation* is not good, but the
>> *functionality*, that is, allowing for the interposition of controls
>> on each system call a process tries to invoke, is both doable and a
>> good thing.
>
> Unfortunately, while doable, it's very hard.  Everything the controller
> looks at must be passed to the kernel in a way that guarantees that
> what the kernel sees is data the controller has vetted.

Yes. It requires that, for example, strings corresponding to paths
being opened be copied into the kernel before they are vetted, and
that the vetting be performed on the canonical version in the kernel,
not on the version in userland that another thread can change. This is
not "very hard", it is just different from the implementation
strategies people have been using to date.

> For simple arguments that are passed in registers, this is easy.
> For self-contained strings like the pathname arguments to calls like
> open() or readlink(), it's a little more difficult, but not all that
> much.
>
> Cases like sendmsg(), where the argument points to a structure that has
> pointers off to other data, are even worse, the more so if those other
> pointers are conditional on something.

The important part in something like sendmsg is to prevent
unauthorized processes from calling it at all, and to prevent
authorized processes from sending to the wrong place. It is not
necessary to vet all the data in practice, so it isn't really a
problem.

> With driver-specific ioctls it's approximately impossible with our
> current kernel setup.

That's not a big deal in that the big issue is preventing processes
from opening devices they're not authorized to touch in the first
place.

> To do this right, we'd have to arrange that copyin() and its relatives
> 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. That said, I would certainly like to see the most general
mechanism available, if only for experiments.

> or at least serviced from memory not writable by anyone else during
> the interval between the controller OKing the call and the kernel
> reading the memory.

The latter seems more reasonable to me -- that is, I would suggest
copying data to the kernel and then vetting and then acting on it.

> And, of course, ideally analogous things should be true for data
> passing in the kernel->user direction too.

Perry
-- 
Perry E. Metzger		perry@piermont.com