Re: NetBSD's veriexec port

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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

'vkernsecurelevel' perhaps?

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

'anklebracelet'

;-)

> 						-Matt

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?)

Bill