Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge

[Avi Kivity]

On 11/09/2009 04:20 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 11/08/2009 12:11 AM, Anthony Liguori wrote:
> > > >  You don't need root privileges to use a tap device.
> > >
> > > You can access a preconfigured tap device but you cannot allocate a 
> > > tap device and connect it to a bridge without CAP_NET_ADMIN.
> >
> > btw, shouldn't we, in the general case, create a bridge per user and 
> > use IP NAT?  If we have a global bridge, users can spoof each other's 
> > MAC addresses and interfere with their virtual machines.
>
> qemu-bridge-helper supports that model quite well :-)  You would 
> create a NAT'd bridge for each user as the administrator, then create 
> a bridge.conf that consisted of per-user includes with appropriate 
> permissions set on each of those files.

Except that the out-of-the-box experience is "go and configure things" 
again.

Really, bridging is fairly complex.  You have to set up the bridge, 
perhaps with NAT, perhaps to the physical device (possibly fighting a 
bit with NetworkManager in that case), allocate MAC addresses in a 
nonconflicting way, set up DHCP, and if you are multiuser, protect users 
from each other, and protect the host from guests.

> >   They can also interfere with the real network.
> >
> > That's not a concern with most one-user-per-machine configurations, 
> > but the default configuration should be safe.
>
> Let's not kid ourselves, no matter what we do we're giving a user 
> elevated privileges.  Even with NAT, if the host can access the NAT'ed 
> network, then you can run a privileged service (like NFS) in that 
> network.  Like it or not, some networks rely on privileged services 
> being trusted as part of their security model (consider NIS).

At least on commercial Linux vendor exports NFS home directories with 
the 'secure' option, requiring a privileged port to mount NFS shares.  
If your patch falls into the wrong hands, virtualization developers 
working at such a vendor might be able to access their home directories 
from guests, which would annoy IT immensely.

> I think the best we can do is provide a tool that allows an 
> administrator to grant users additional privileges in the tiniest 
> increments possible.  Putting people in wheel just so they can do 
> virtualization is too much.

I'm concerned that we're confusing the situation instead of clearing 
it.  Telling users to "edit /etc/foo/bar" so you can run bridging 
without fully explaining the impact is not responsible.  Trusting 
libvirt to do it end-to-end is fine, but in this case it can also set up 
the tap itself.

> I don't see having an fscap-based helper as creating policy.  I see it 
> as adding a mechanism for administrators to create policy.

I'll summarize my current issues with the patchset:

- by introducing an suid/fscap helper we're expanding the scope of 
security in qemu.  In addition to protecting qemu against malicious 
guests trying to gain local user privileges, we need to protect it 
against malicious local users trying to gain root (or CAP_NET_ADMIN) 
privileges

- we're introducing yet another authorization mechanism.  We have 
enough.  We already have feedback that policykit is wanted in at least 
some cases.  Given that authorization is best kept consistent in a 
distro, and that distros try to be as inconsistent from each other as 
possible, we can't please everyone.

- for the command-line user, we aren't providing a full solution; they 
still have a lot of configuration to do before things work (especially 
if they don't already have a network segment with DHCP)

- for libvirt and other management systems, it is insufficient since 
they will at least in some cases need to perform privileged 
configuration before handing the tap to the guest.  So they still need 
to be privileged and they can't use -net bridge for hotplug.

I would be happier if we drop suid/fscap from the helper.  We can have a 
user-provided script or binary gain the necessary privileges (using sudo 
or policykit or whatever).  This way we don't need to deal with local 
privilege escalation vulnerabilities.

--
error compiling committee.c: too many arguments to function