On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore <address@hidden> wrote:
On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore <address@hidden> 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.
Don't we have some basic understanding of what the applications being exec'd
will need to do? I sorta see your point, but allowing the entire set of
syscalls seems a bit dramatic.
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by smbd (for some version of it)
can be known. The user could specify arbitrary commands for the
others, those could be assumed to use some common (large) subset of
system calls but I think the security value would be close to zero
then.
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.
When I spoke to Anthony about this earlier (offline, sorry) he was opposed to
requiring any switches or user interaction to enable seccomp. I'm not sure if
his stance on this has changed any over the past few months.
There could be two modes, strict mode (-seccomp) and default mode
(only some syscalls blocked). With the future decomposed QEMU, strict
seccomp mode would be default and the switch would be obsoleted. If
the decomposition is planned to happen soonish, adding the switch
would be just churn.
In my perfect world, we would have a decomposed QEMU that functions as a
series of processes connected via some sort of IPC; the exact divisions are a
bit TBD and beyond the scope of this discussion. In this scenario we would be
able to restrict QEMU with sVirt and seccomp to a much higher degree than we
could with the current monolithic QEMU.
I don't expect to see my perfect world any time soon, but in the meantime we
can still improve the security of QEMU on Linux with these seccomp patches and
for that reason I think it's a win. Since these patches don't expose anything
at runtime (no knobs, switches, etc.) we leave ourselves plenty of flexibility
for changing things in the future.
Yes, I'm much in favor of adding seccomp support soon. But I just
wonder if this is really the best level of security we can reach now,
not assuming decomposed QEMU, but just minor tweaks?
--
paul moore
security and virtualization @ redhat