Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen <ak@suse.de>]

On Wednesday 12 July 2006 23:22, Ingo Molnar wrote:

> 
> i think Andrea didnt even try to fix/generalize ptrace perhaps because 
> that would make his 'security feature' too banal? 

seccomp in its current state is already "banal". I think that was the
whole point of it. If he had wanted to do something complicated I'm sure
LSM would have offered lots of opportunity to go wild @). But seccomp
is really simple and easy to analyze. I bet if he could have made
it simpler he would have done that too.

That said the problems I see with using ptrace for this is that it
just adds too many context switches for each syscall and would be likely too slow.
Hmm, actually there might not be that many syscalls for these applications
(just some reads and writes) so it might work or not. But it would certainly be slower 
than it is right now. Would probably need some testing.

If utrace allows to do the filtering in kernel space it would 
be probably a useful replacement. I don't remember enough of the code
to know if it can do this or not. But I suppose it would still
need a kernel module or kernel patch of some sort to implement this
specific filtering.

> there's 
> nothing inherently insecure about the _client side_ of the ptrace APIs 
> or the client side of ptrace implementation. 

Agreed. 

> So my suggestion is to get  
> utrace in, to implement an utrace module that implements untrusted code 
> execution and then lets get rid of seccomp.

Sounds fine to me in theory (without having looked at any code) 

-Andi