Re: [libvirt] [PATCH] Default to qemu:///system if accessible

On 06-09-2010 13:22, Daniel P. Berrange wrote: > On Mon, Sep 06, 2010 at 01:07:34PM +0200, Soren Hansen wrote: >> On 06-09-2010 12:24, Daniel P. Berrange wrote: >>> On Mon, Sep 06, 2010 at 12:16:40PM +0200, Soren Hansen wrote: >>>> On 06-09-2010 11:17, Daniel P. Berrange wrote: >>>>> Our goal is to improve qemu://session's networking such that >>>>> this isn't a reason to use qemu://system anymore >>>> Fair enough, but when that happens, I'm supposing people won't >>>> have access to the system-wide UNIX socket anymore. >>> No, we won't change access to the system instance, the policy >>> for that is already configurable per-host by admins if they so >>> desire. >> Yes, that's what I meant. If qemu:///session turns useful enough, >> admins won't give users access to the privileged UNIX socket. > Or they'll leave the permissions 0777 and simply change the policykit > rule to deny access, or they'll not change anything, and simply not > tell the user the root password, which is what's required to be > entered with policykit to access qemu:///system. I understand. I wrote the above under the (false) assumption that having write access to the UNIX socket implied having privileges to the system's libvirtd. >>>> I disagree. In both of those cases, I'd be surprised if people >>>> were able to access the privileged libvirtd socket. In the >>>> former case, if people generally had access to the systemwide >>>> libvirtd instance, I'd assume that was because that was the >>>> one they were supposed to use for their shared development >>>> stuff. In the latter case, with that sort of access, I could >>>> have full root shell access within minutes, so that'd be a >>>> pretty big security fail. >>> You are equating access to the UNIX socket, with authorization to >>> the unix socket. >> Indeed I am. > Therein lies the flaw in this approach. Yes, I learned that a few lines further down. :) >>> With PolicyKit auth enabled by default, the UNIX socket is mode >>> 0777 at all times, but this does not imply that all users are >>> able to use it. They can connect, but if PolicyKit denies them, >>> their connection will be dropped by the server. >> Fascinating. I had no idea. That's a very convincing argument :) >> What if I could come up with a check for whether the user would be >> authorized to access the socket? Like including a auth_unix_rw == >> "none" condition in the check? Would that change your view at >> all? > PolicyKit is just one example I happened to pick, auth_unix_rw == "none" was also just an example. > the same logic applies to any of the other > authentication/authorization methods that libvirtd applies. Of course. > Any check based on socket permissions is fundamentally flawed, I feel the same way about one that is based on uid, to be honest. > even with auth_unix_rw="none" (which you can't check because a > non-root user can't read /etc/libvirt/libvirtd.conf), On Ubuntu, /etc/libvirt/libvirtd.conf is mode 0644? Should I be worried about that? A quick glance in there doesn't reveal anything that I'm uncomfortable disclosing.

> when we add role based access control, you may be able to connect to > the 'rw' socket, but have no more privileges than on the 'ro' > socket. In that particular case, I could also check for whether RBAC was enabled, but that's really beside the point right now. My question was a general one: Assuming I can determine that a given user is authorized to manage the systemwide libvirtd, would you agree that that is the one they're most likely to want to access? I simply cannot think up a realistic example use case where someone has this privilege, but actually wants to access qemu:///session.