Red Hat Bugzilla – Bug 1284447
libvirt group is unauthenticated root equivalent
Last modified: 2015-11-27 22:20:39 EST
Description of problem:
Placing a user in the 'libvirt' group gives them unauthenticated root access.
While this is better than the prior situation with the 'docker' group as the privilege escalation happens via polkit and thus can be logged, it is still surprising that adding the user to a group gives them unauthenticated root access on a Fedora system.
The group named 'libvirt' can either come from a local source, or from a remote source.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. usermod -G libvirt -a user
Received confirmation here that libvirt system access is root equivalent:
I had assumed that libvirt system access is root equilavent given the container API, but I have not explored this or exploited this myself.
It may be that Fedora is okay with certain groups being unauthenticated root equivalent. For example Fedora Cloud has a sudoers file that allows unauthenticated root escalation.
However this should be vetted and properly considered.
Yes, the "libvirt" group should essentially be considered equivalent to the "wheel" group in concept. Indeed we could have just used the wheel group for libvirt access instead, however, we felt it is desirable to have a separate group as that allows more fine grained control. The 'libvirt' group membership merely gives you permission to connect to the libvirtd daemon. Once connected there is still the ability to restrict what the user can do, via libvirt's fine grained access control mechanism. So while it is correct that the default configuration is equivalent to root, you can use libvirt access control (which is also done via polkit - http://libvirt.org/aclpolkit.html) to reduce the privileges implied by "libvirt" group membership.
The difference is:
* The wheel group requires reauthorization (in most cases a password prompt) on
a default Fedora install in order to escalate privileges.
* The libvirt group escalates privileges without a reauthorization prompt.
(In reply to Stef Walter from comment #2)
> The difference is:
> * The wheel group requires reauthorization (in most cases a password
> prompt) on
> a default Fedora install in order to escalate privileges.
> * The libvirt group escalates privileges without a reauthorization prompt.
right, but people will use the 'libvirt' group over 'wheel' because they _dont_ have to reauth. people regularly do the equivalent thing with NOPASSWD: ALL sudo. maybe it's suboptimal but it's a familiar pattern.
the reason we added this libvirt group is to just standardize it: people were doing equivalent hacks all over the place, I've probably seen 10 blog posts and a dozen more mails describing how to hack it in. debian and suse were shipping similar rules before we added it upstream. so I guarantee that even if we require the wheel-similar reauth, many people are just going to work around it anyways, _including_ apps live vagrant (or vdsm or nova) shipping similar rules
in the vagrant bug you said: 'It's even worse that unconditional nopasswd access via sudo, since that's logged and audited.'
I hadn't heard that bit before... does polkit do no logging here? maybe we can fix polkit, or the polkit rules file, to do appropriate logging? can you expand on what type of logging sudo does?
As Cole says, membership of the libvirt group is working entirely as designed. If admins don't want users to use libvirt without re-authorization they can simply not add users to the libvirt group, or they can customize the polkit rule locally to require re-auth. I'm closing on the basis that this is working as designed.
If there's a gap in logging of polkit authorizations, then a bug can be filed against polkit for that.