Re: [-mm patch] seccomp: don't say it was more or less mandatory

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

> see my earlier counter-arguments in the thread starting at:
> 
>   http://marc.theaimsgroup.com/?l=linux-kernel&m=110630922022462&w=2
> 
> end result of the thread: seccomp is completely unnecessary code-bloat
> and can be equivalently implemented via ptrace. I cannot believe this
> made it into -BK ...

let me moderate my initial reaction somewhat:

the point i see in seccomp is that while it cannot be trusted right now
(not because of any known factor but simply because it doesnt have
enough review, yet), it might at a certain point (in many years) become
more trustable than TRACE_SYSCALLS.

It doesnt use a 'server' process to control syscall execution,
everything is enforced by the kernel. It is also intentionally simple,
and hence maybe even provably secure from a Comp-Sci POV. (assuming
sys_read()/sys_write() and hardware-irq processing itself is secure,
which quite likely wont be provable in the foreseeable future).

Also, while the technological arguments i raised in support of ptrace
are true, ptrace has a perception issue: it is perceived as insecure -
even if PTRACE_TRACE itself is not affected. And when building trust in
a processing platform, perception is just as important as raw security.

this combination of arguments i think tips the balance in favor of
seccomp, but still, i hate the fact that the anti-ptrace sentiment was
used as a vehicle to get this feature into the kernel.

technical comment: seccomp goes outside the audit/selinux framework,
which i believe is a bug. Andrea?

	Ingo