NetBSD's veriexec port

[Bill Hacker]

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