Bug 1284447 - libvirt group is unauthenticated root equivalent
libvirt group is unauthenticated root equivalent
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-23 06:08 EST by Stef Walter
Modified: 2015-11-27 22:20 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 13:55:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stef Walter 2015-11-23 06:08:20 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):

libvirt-1.2.18.1-2.fc23.x86_64

How reproducible:

Every time.

Steps to Reproduce:
1. usermod -G libvirt -a user
2. virt-manager

Additional info:

Received confirmation here that libvirt system access is root equivalent:

https://bugzilla.redhat.com/show_bug.cgi?id=1187019#c16

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.

https://fedoraproject.org/wiki/Privilege_escalation_policy
Comment 1 Daniel Berrange 2015-11-23 06:32:02 EST
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.
Comment 2 Stef Walter 2015-11-23 06:34:15 EST
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.
Comment 3 Cole Robinson 2015-11-23 13:39:31 EST
(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?
Comment 4 Daniel Berrange 2015-11-23 13:55:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.