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