DragonFly kernel List (threaded) for 2009-10
Re: NetBSD's veriexec port
Matthew Dillon wrote:
I'm only luke-warm on the concept. I would much rather see improvements
in the virtual kernel technology w/ regards to ease of use, features,
and performance. I think we risk serious fragmentation of the security
space by implementing all these weird little security features that
we are more likely to trip over then anything else.
One thing that would be very cool would be a system call that locks out
all new file descriptor-creating system calls (like open, socket, etc),
and also locks out namespace functions like remove(), chmod(), and
functions like fork() and exec*(). The idea being that you would be
able to start a vkernel and the vkernel would make this system call
after setting up its virtual network and disk, but before starting the
Another cool feature would be a similar system call which does a
soft-chroot (I just made up that name)... Modifying filesystem
calls would only be allowed within the soft-chroot, but the real
root of the filesystem would still be whatever it was before. The
idea here is that you might have an application which you'd rather
not trust but which performs important functions on your behalf, and
you want an easy way to run it without giving it the ability to mess
around with your entire account.
There's plenty of prior art for the first.
The second? - is that akin to applying (v)kernel-class restrictions at a
userspace level? Restricting access to API's? Snifing calls for safety?
Or? (spawning an ephemeral vkernel on-the-fly?)