Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c

[Paul Moore <pmoore@redhat.com>]

On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore <pmoore@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.

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.

> > 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.

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.

-- 
paul moore
security and virtualization @ redhat