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

[Soren Hansen]

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/