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 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. > > 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, the same logic applies to any of the other authentication/authorization methods that libvirtd applies. Any check based on socket permissions is fundamentally flawed, even with auth_unix_rw="none" (which you can't check because a non-root user can't read /etc/libvirt/libvirtd.conf), 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. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
