>> 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,

No, there are other ways of achieving it - for example, the kernel
could fetch the path from the controller's address space rather than
from the controlled process's, or the page(s) involved could be marked
such that attempts to write to them suspend the writing process until
after the syscall is known to have fetched everything it needs.

Unless that's what your "for example" meant; in that usage, it seems to
me to mean "among other things" more than "as one possibility".

> This is not "very hard", it is just different from the implementation
> strategies people have been using to date.

No, for pathnames passed directly to syscalls it is not very hard.  To
do it right - which involves a lot more than just pathnames - is.

>> 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,

If that's all you care about, lucky you.  Not everyone is so fortunate.

> and to prevent authorized processes from sending to the wrong place.

So you have to follow - and ensure the kernel gets a vetted version of
the data at - at least one of the pointers in the msghdr.

> It is not necessary to vet all the data in practice, so it isn't
> really a problem.

Not necessary to vet all the data, no, not in most cases - but I think
it would be a huge mistake to cripple any such facility by preventing
it from vetting some of the data involved; I can't know which pieces of
data tomorrow's sandboxing will care about and which not.

>> 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.

You make very free with telling other people what kind of security
sandboxing they (don't) need to do.

>> 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.

That's one reasonable way to achieve that, but far from the only way -
and it requires either hooking copyin and friends or changing
everywhere that uses them.

Or, of course, telling people trying to build security sandboxes that
they don't need to be able to vet the more difficult pieces of data.  I
know I certainly wouldn't appreciate that.

Still, it might be acceptable as a first cut.  ktrace can't print a lot
of useful things, either, and it's still useful in a large set of
circumstances (but there have been cases where I've used trc rather
than ktrace because I needed one of those things ktrace couldn't
print).  And since I'm not planning on being the one doing the work....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B