[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
Date: Tue, 10 Nov 2009 14:23:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]