Re: secure computing for 2.6.7

[Andrew Morton <akpm@osdl.org>]

andrea@cpushare.com wrote:
>
> I need this new kernel feature for a reseach spare time project I'm
>  developing in the weekends.  The fast path cost is basically only the
>  s/testb/testw/ change in entry.S. (and even that might be removed with a
>  more signficant effort but I don't think anybody could worry about that
>  change).
> 
>  This might be better off for 2.7 but I would like if people could have a
>  look, and it's simple enough that it might be included in 2.6 too later
>  on. (it just need to be ported to the other archs, only x86 is
>  implemented here, but that's easy)
> 
>  Especially I would like to know if anybody can see an hole in this. This
>  is an order of magnitude more secure of chroot and of capabilities and
>  much simpler and it doesn't require root privilegies to activate. I
>  wasn't forced to take secure computing down into kernel space but I
>  believe it's the simplest and most secure and most efficient approch. An
>  userspace alternative would been to elaborate this below bytecode
>  userspace approch but besides being an order of magnitude slower it also
>  is a lot more complicated and less secure, and it keeps into the
>  equation the virtual machine that executes the code later on:
> 
>  	http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286134

I'm not sure what to say about this, really.

Of course, yes, the patch is sufficiently safe and simple for it to be
mergeable in 2.6, if this is the way we want to do secure computing.  I'd
wonder whether the API should be syscall-based rather than /proc-based, and
whether there should be a config option for it.

But the wider questions are stuff like "where is all this coming from",
"where will it all end up" and "what are the alternatives".