[libvirt] RFC: stop clearing QEMU emulator capabilities

Daniel P. Berrangé berrange at redhat.com
Thu Nov 28 13:04:00 UTC 2019


We have an RFE from libguestfs to provide a way to run as root
*with* capabilities. I looked integrating this into the DAC security
manager as a new flag in the security label, but then I started
thinking about the whole idea of clearing capabilities

  https://bugzilla.redhat.com/show_bug.cgi?id=1045039

Pretty much forever we have explicitly cleared QEMU emulator
capabilities when starting it.

When QEMU uid/gid is set to non-root this is pointless as if we just
used a regular setuid/setgid call, the process will have all its
capabilities cleared anyway by the kernel.

When QEMU uid/gid is set to root, this is almost (always?) never
what people actually want. People make QEMU run as root in order
to access some privileged resource that libvirt doesn't support
yet and this often requires capabilities. As a result they have
to go find the qemu.conf param to turn this off. This is not
viable for libguestfs - they want to control everything via thue
XML security label to request running as root regardless of the
qemu.conf settings for user/group.

Clearing capabilities was implemented originally because there
was a proposal in Fedora to change permissions such that root,
with no capabilities would not be able to compromise the system.
ie a locked down root account. This never went anywhere though,
and as a result clearing capabilities when running as root does
not really get us any security benefit AFAICT. The root user
can just do something like create a cronjob, which will then
faithfully be run with full capabilities, trivially bypassing
the restriction we place.

IOW, our clearing of capabilities is both useless from a security
POV, and breaks valid use cases when people need to run as root.

I'm  thinking we should just rip out the code which clears capabilities
and allow default loggic to run

 - If uid/gid is non-root, then no capabilities are present
 - If uid/gid is root, then full capabilities are present

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