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. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/