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

[Daniel P. Berrange]

On Mon, Sep 06, 2010 at 02:03:08PM +0200, Soren Hansen wrote:
> 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.

The /etc/libvirt directory itself should be 0700 though, since various
files under that location include passwords (qemu.conf, secrets/*,
qemu/*xml, lxc/*xml, uml/*xml). We don't currently have any passwords
in libvirtd.conf itself, but its certainly possible this might change
in the future. While it is possible to rely on getting each individual
file there to have correct permissions, IMHO it is safer to make the 
/etc/libvirt directory 0700

> > 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.

No, I don't agree. I already mentioned the reasons why it is desirable
to run within the user session - SDL, audio, disk permissions, and to
add another one gnome-keyring integration for qcow2 passwords which is
a future feature we'd like for the secrets driver. IMHO if we are to get
better integration into the user's desktop experiance, then having both
libvirtd & the VMs running in the user's context, rather than a separate
context is key.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|