On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore <pmo...@redhat.com> wrote: > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote: >> I think allowing execve() would render seccomp pretty much useless. > > Not necessarily. > > I'll agree that it does seem a bit odd to allow execve(), but there is still > value in enabling seccomp to disable potentially buggy/exploitable syscalls. > Let's not forget that we have over 300 syscalls on x86_64, not including the > 32 bit versions, and even if we add all of the new syscalls suggested in this > thread we are still talking about a small subset of syscalls. As far as > security goes, the old adage of "less is more" applies.
The helper program being executed could need any of the 300 system calls, so we'd have to allow all. > > Protecting against the abuse and misuse of execve() is something that is > better done with the host's access controls (traditional DAC, MAC via the LSM, > etc.). How about seccomp mode selected by command line switch -seccomp, in which bind/connect/open/execve are forbidden? The functionality remaining would be somewhat limited (can't migrate or use SMB etc. until refactoring of QEMU), but that way seccomp jail would be much tighter. > > -- > paul moore > security and virtualization @ redhat >
