DragonFly BSD
DragonFly kernel List (threaded) for 2009-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: NetBSD's veriexec port

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Wed, 14 Oct 2009 11:19:19 +0800

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.




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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]