Bug 1187019
| Summary: | Avoid polkit password prompts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> |
| Component: | vagrant-libvirt | Assignee: | Vít Ondruch <vondruch> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | crobinso, erik-fedora, hhorak, madam, pvalena, rct+redhat, stefw, tim, vondruch |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | vagrant-libvirt-0.0.45-1.fc30 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1168333 | Environment: | |
| Last Closed: | 2019-02-14 08:13:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1168333 | ||
| Bug Blocks: | |||
|
Description
Vít Ondruch
2015-01-29 08:01:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 As an aside, this bug could become moot if this issue is fixed instead: https://github.com/pradels/vagrant-libvirt/issues/272 I highly recommend trying to do this :) Cheers, James Note that upstream libvirt now ships a polkit rule that means any user in the 'libvirt' group can avoid password prompts: https://bugzilla.redhat.com/show_bug.cgi?id=957300 I plan on backporting this to f22 as well. So that will help here but it won't work out of the box. Though making vagrant work with qemu:///session is definitely good too... From a system security perspective, having passwordless vagrant off by default makes sense, but it would be good if there was a standard utility whereby a user that *already* has root access can give themselves permanent permission to run vagrant without being asked for their password all the time. Developer desktops are not servers :)
I'm not sure it makes sense for such a utility to be Vagrant specific though.
The kind of UX I am thinking of here would be something like:
$ sudo dnf install vagrant-libvirt
$ accessctl grant vagrant
$ vagrant up
<enjoy your passwordless vagrant!>
So users would remain protected by default, but devs that wanted to avoid the password prompts would have an easy way to turn them off. Make it plugin based and we may also be able to have things like:
$ accessctl grant mock
$ accessctl grant docker
Other subcommands would be "revoke" and "list".
That way developers wouldn't need to care whether the backend implementation of the permissions management was "add yourself to this group" or "add this polkit policy" or something else entirely, they'd just need to know to grant themselves the appropriate permission through accessctl.
(In reply to Nick Coghlan from comment #4) > From a system security perspective, having passwordless vagrant off by I think the best solution would be to have someone work on: https://github.com/pradels/vagrant-libvirt/issues/272 (In reply to Nick Coghlan from comment #4) > From a system security perspective, having passwordless vagrant off by > default makes sense, but it would be good if there was a standard utility > whereby a user that *already* has root access can give themselves permanent > permission to run vagrant without being asked for their password all the > time. Yeah, I would prefer that standard utility to be “add yourself to a group”. Now that IPA and sssd supports groups-of-groups, we can have user-defined groups (departments, ”$site administrators” and the like) for arbitrary grouping, and application-defined role groups (”those allowed to run vagrant”) for permission checking: the role groups can contain both individual users and user-defined groups. Groups are a well-understood mechanism and if we don’t really need a different mechanism, I would prefer to not add a new parallel not-quite-a-group mechanism. And libvirt/vagrant is already using this design, which is great. In the meantime, I and phracek, started to work on Vagrant DevAssistant[0] that can easily set this up! This way we can also keep adding other setups like effortless NFS and such. [0] https://dapi.devassistant.org/dap/vagrant/ The polkit rules here are fundamentally broken from a Fedora security perspective (and the security policy of many other linux based operating systems as well): http://pkgs.fedoraproject.org/cgit/vagrant-libvirt.git/tree/10-vagrant-libvirt.rules Those who can call the libvirt API can execute whatever they want as root and hose the system. Using the above linked rule to grant access to the vagrant group to unconditionally and without authentication, audit or logging to escalate to root privileges is a broken default. Note that we recently fixed a similar hole by having a docker group that allowed unconditional and unlogged escalation to root. It's fine if people want to have this vagrant group on their own systems, but these polkit rules should not get merged into Fedora as is. From a security perspective, it is essentially the same as running your login session as root. It's even worse that unconditional nopasswd access via sudo, since that's logged and audited. What vagrant-libvirt can and should do if it wants to use the qemu://system is one or both of: * Support use via sudo correctly. One should be able to 'sudo vagrant up' ... much like one can 'sudo docker run ...' * Open a per tty connection to libvirtd using a background process. The privilege escalation prompt will happen once per tty (ie: terminal). Alternatively, vagrant could use qemu://session ... although that still has some privilege escalation issues with regard to networking: https://github.com/pradels/vagrant-libvirt/issues/272 I'm all for fixing this, but it should be fixed correctly, not by voiding default system security. (In reply to Stef Walter from comment #8) > > Those who can call the libvirt API can execute whatever they want as root > and hose the system. Using the above linked rule to grant access to the > vagrant group to unconditionally and without authentication, audit or > logging to escalate to root privileges is a broken default. If this is true (and I believe you) then it's a serious issue, and we can't include the polkit rule by default. To enrich my brain, is there a POC or some example you can refer me to, so I can see how this is possible? > What vagrant-libvirt can and should do if it wants to use the qemu://system > is one or both of: > > * Support use via sudo correctly. One should be able to 'sudo vagrant up' The sudo path is problematic, in particular if vagrant or omv makes a log file or similar, since it would have root perms in the users dir. > Alternatively, vagrant could use qemu://session ... although that still has > some privilege escalation issues with regard to networking: > > https://github.com/pradels/vagrant-libvirt/issues/272 Agreed... I'm not sure how the networking problem can be solved, but logically it must be possible, since a network could be virtual and run in user space, with only a pre-existing network used to route publicly. (In reply to James (purpleidea) from comment #9) > (In reply to Stef Walter from comment #8) > > > > Those who can call the libvirt API can execute whatever they want as root > > and hose the system. Using the above linked rule to grant access to the > > vagrant group to unconditionally and without authentication, audit or > > logging to escalate to root privileges is a broken default. > > If this is true (and I believe you) then it's a serious issue, and we can't > include the polkit rule by default. To enrich my brain, is there a POC or > some example you can refer me to, so I can see how this is possible? The most obvious is in libvirt-lxc, where you can specify the supervisor. Search for <init> on this page: https://libvirt.org/formatdomain.html But there are lots of places where libvirt executes scripts or executables. 'git grep virCommandRun' will get you started. Most importantly though, the libvirt developers will tell you the same thing: https://bugzilla.redhat.com/show_bug.cgi?id=890291#c16 (In reply to Stef Walter from comment #10) > (In reply to James (purpleidea) from comment #9) > > (In reply to Stef Walter from comment #8) > > > > > > Those who can call the libvirt API can execute whatever they want as root > > > and hose the system. Using the above linked rule to grant access to the > > > vagrant group to unconditionally and without authentication, audit or > > > logging to escalate to root privileges is a broken default. > > > > If this is true (and I believe you) then it's a serious issue, and we can't > > include the polkit rule by default. To enrich my brain, is there a POC or > > some example you can refer me to, so I can see how this is possible? > > The most obvious is in libvirt-lxc, where you can specify the supervisor. > Search for <init> on this page: > > https://libvirt.org/formatdomain.html > > But there are lots of places where libvirt executes scripts or executables. > 'git grep virCommandRun' will get you started. > > Most importantly though, the libvirt developers will tell you the same thing: > > https://bugzilla.redhat.com/show_bug.cgi?id=890291#c16 Very interesting, thanks. TIL another way to get root ;) At least it's clear to me that https://github.com/pradels/vagrant-libvirt/issues/272 and figuring out how to keep networking happy is the way to go. Please note that since libvirt-1.2.9.3-2.fc21 [1], there is shipped PolKit rule, which is essentially exactly the same rule we are currently shipping in vagrant-libvirt. The only difference is that libvirt requires user to be added into libvirt group instead of vagrant group. I'm considering to drop the rule and the vagrant group from vagrant-libvirt entirely and suggest users to use the libvirt group instead. Of course this would apply just to F24+, to there is approximately 6 months to update documentation, etc. There should not be any backward compatibility concern. Of course support for the user session [2] is the preferred solution. [1] http://pkgs.fedoraproject.org/cgit/libvirt.git/commit/?h=f21&id=b59373e03c2da66d7aabce2c6a9b09e193435f0b [2] https://github.com/pradels/vagrant-libvirt/issues/272 Is the libvirt group root equivalent? This is the upstream polkit .rules file: https://github.com/libvirt/libvirt/blob/master/daemon/libvirt.rules So then the question is whether having libvirt qemu+kvm:///system access is root equivalent or not. (In reply to Stef Walter from comment #15) > So then the question is whether having libvirt qemu+kvm:///system access is > root equivalent or not. Yes it is root equivalent. Everything you mention about libvirt in comment #8 is correct. Though libvirt does have audit rules so things aren't completely unlogged. But this is the first I've heard about polkit rules of that nature being a bad idea from a security logging perspective... can you file a libvirt bug so we can discuss there? (In reply to Cole Robinson from comment #16) > can you file a libvirt bug so we can discuss there? And link it here please :) Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Libvirt now ships polkit ruiles, but this should be better IMO. This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. No change here, except that the upstream ticket about qemu://session was rejected :/ https://github.com/vagrant-libvirt/vagrant-libvirt/issues/272#issuecomment-214398425 This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. There seems to be developement using QEMU session: https://github.com/vagrant-libvirt/vagrant-libvirt/pull/868 Not sure how to proceed though, as it's not used by default. Also requires `qemu-bridge-helper`[0] is required, additionally and some root-powered features in Vagrant might not work. [0] https://wiki.qemu.org/Features/HelperNetworking (In reply to Pavel Valena from comment #25) Nice. Once this is released, it seems it will be enough to change this [1] line to make the qemu:///session default. The question is if we want to. It will probably need some testing. [1] https://github.com/vagrant-libvirt/vagrant-libvirt/blob/e696032debe485b4af346aa75569c55c5fadf903/lib/vagrant-libvirt/config.rb#L654 This is now available in Rawhide as part of https://fedoraproject.org/wiki/Changes/Vagrant_2.2_with_QEMU_Session |