[libvirt] [PATCHv2 4/4] qemu: deny privilege elevation and spawn in seccomp
Daniel P. Berrangé
berrange at redhat.com
Fri Apr 13 14:23:37 UTC 2018
On Fri, Apr 13, 2018 at 10:08:34AM -0400, John Ferlan wrote:
>
>
> On 04/10/2018 10:49 AM, Ján Tomko wrote:
> > If QEMU uses a seccomp blacklist (since 2.11), -sandbox on
> > no longer tries to whitelist all the calls, but uses sets
> > of blacklists:
> > default (always blacklisted with -sandbox on)
> > obsolete (defaults to deny)
> > elevateprivileges (setuid & co, default: allow)
> > spawn (fork & execve, default: allow)
> > resourcecontrol (setaffinity, setscheduler, default: allow)
> >
> > If these are supported, default to sandbox with all four
> > categories blacklisted.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1492597
> >
> > Signed-off-by: Ján Tomko <jtomko at redhat.com>
> > ---
> > src/qemu/qemu.conf | 7 +++---
> > src/qemu/qemu_command.c | 10 +++++++++
> > tests/qemuxml2argvdata/minimal-sandbox.args | 29 ++++++++++++++++++++++++
> > tests/qemuxml2argvdata/minimal-sandbox.xml | 34 +++++++++++++++++++++++++++++
> > tests/qemuxml2argvtest.c | 11 ++++++++++
> > 5 files changed, 88 insertions(+), 3 deletions(-)
> > create mode 100644 tests/qemuxml2argvdata/minimal-sandbox.args
> > create mode 100644 tests/qemuxml2argvdata/minimal-sandbox.xml
> >
> > diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> > index 07eab7eff..740129cf5 100644
> > --- a/src/qemu/qemu.conf
> > +++ b/src/qemu/qemu.conf
> > @@ -669,9 +669,10 @@
> >
> >
> >
> > -# Use seccomp syscall whitelisting in QEMU.
> > -# 1 = on, 0 = off, -1 = use QEMU default
> > -# Defaults to -1.
> > +# Use seccomp syscall sandbox in QEMU.
> > +# 1 = on, 0 = off, -1 = use the default
> > +# For QEMUs using a whitelist, the default (-1) is off.
> > +# For QEMUs using a blacklist, the default (-1) is on.
>
> Not sure it's even possible to provide any sort of details, but suffice
> to say the description here is really lacking. One of those things that
> if you know and care, then you use, if you don't you ignore. Maybe it's
> just me being dense ;-).
>
> Still if someone supplies 0 or 1 does that now mean the opposite of what
> it did before 2.11? That is if I had this set to 1 in my qemu.conf -
> does that mean that now I'm using a blacklist instead of a whitelist?
Yes, setting this to '1' just means "enable use of seccomp". We explicitly
never defined what kind of seccomp rules would be enabled - only that
something seccomp related is on. Whether its a blacklist or a whitelist
is a low level impl detail that we don't expect users to care about.
> As an Admin trying to decipher this - what would each setting mean to me
> and if going with the new -1 default, then that means libvirt is going
> to set "on" w/ a list of 4 to deny.
Essentially the default (-1) means "do the best thing". On old QEMU the
best thing was to disable it because it was horribly unreliable with a
whitelist. On modern QEMU the best thing is to enable it because the
blacklist is much saner
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list
mailing list