[libvirt] RFC: stop clearing QEMU emulator capabilities
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 :|
On Thu, Nov 28, 2019 at 01:04:00PM +0000, Daniel P. Berrangé wrote:
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
All seems reasonable to me ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On 11/28/19 8:16 AM, Richard W.M. Jones wrote:
On Thu, Nov 28, 2019 at 01:04:00PM +0000, Daniel P. Berrangé wrote:
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 All seems reasonable to me ...
+1. I wasn't aware of the history behind it, but that all makes sense.
On 11/28/19 2:04 PM, Daniel P. Berrangé wrote:
I don't recall the exact details, but I remember I had to disable clearing capabilities temporarily (I vaguely recall it had something to do with device assignment). What I am trying to say is that clearing capabilities may sometimes get in our way. So I agree with not clearing them and relying on the rest of security mechanisms we have. Michal
participants (4)
-
Daniel P. Berrangé -
Laine Stump -
Michal Privoznik -
Richard W.M. Jones