Re: [-mm patch] seccomp: don't say it was more or less mandatory
From: Ingo Molnar
Date: Tue Mar 15 2005 - 06:29:31 EST
* Ingo Molnar <mingo@xxxxxxx> wrote:
> see my earlier counter-arguments in the thread starting at:
> 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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/