Bug 1284447
| Summary: | libvirt group is unauthenticated root equivalent | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stef Walter <stefw> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | agedosier, berrange, clalancette, crobinso, itamar, jforbes, jshubin, laine, libvirt-maint, madam, veillard, virt-maint, vondruch |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-23 18:55:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Stef Walter
2015-11-23 11:08:20 UTC
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. |