* Ingo Molnar <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/