Messages in this thread | | | Date | Sun, 23 Jan 2005 01:46:07 +0100 | From | Andrea Arcangeli <> | Subject | Re: seccomp for 2.6.11-rc1-bk8 |
| |
On Sun, Jan 23, 2005 at 01:07:04AM +0100, Pavel Machek wrote: > Adding code is easy, but in the long term would lead to maintainance > nightmare. Adding seccomp code that does subset of ptrace, just > because ptrace audit is lot of work, seems like a wrong thing to > do. Sorry.
Even if I do the ptrace audit right now, within 6 months something can change and the implications of the changes won't be as trivial to evaluate as if entry.S or seccomp.c have changed.
The userland side will be a lot more complicated too to implement.
Do you want video compressed strems to be played securely and efficiently? I can't see a better solution than seccomp. ptrace would be slower and it'd require ugly code to be written in userland. Streams are going to pump some stuff into the pipes and this will avoid quite a number of schedules per second (regardless of buffering). The seccomp API is just tricky enough without having to hardcoded into every userland app the number of the syscalls. Seccomp at least gives a slight chance to write arch indipendent code while still providing lowlevel security from the OS, there's no way to use ptrace_syscall in a arch indipendent manner.
In the last patch I sent privately to Andrew I made it a config option, but I recommend not to disable it, or you won't be able to run the Cpushare client. Andrew's right seccomp.o would waste precious bytes (not kbytes) on embedded systems, so it has to be a config option for that. You can still modify it to use ptrace freely, but then I will have nothing to do with the problems that may arise over time by using ptrace within the GPL'd Cpushare client code and I personally do not approve the use of ptrace there (but it's GPL so you can modify it). I'm doing something that I can trust to run on my own desktop system, and personally seccomp is the only thing I'm confortable to depend on. Plus the userland gets so much simpler as well. It's not only a problem of trusting the kernel space of ptrace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |