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