On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore 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.
I can sort of see this argument, but *only* if the QEMU process is being
run under a dedicated, fully unprivileged (from a DAC pov) user, completely
separate from anything else on the system.
If QEMU were being run as root, then even with seccomp, it could trivially
just overwrite some binary in /bin, update /proc/core-pattern to point to
this binary, and then crash itself. Now that core handling binary will
execute without any of the seccomp filters applied.
Similarly if QEMU is being run in the user's desktop session, I'm sure there
is some kind of similar attack possible by changing a config setting for the
user's GNOME/KDE session, and then waiting for GNOME/KDE to execute the script
that QEMU just wrote out, once again bypassing seccomp.
Regards,
Daniel