qemu no tun/tap networking

Is this symptom still reproducible in 8.10 beta?

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

This bug is still existing in Interpid. What information exactly is needed, so I could provide it?

Thanks for the report. This is a security issue. The kernel requires more privileges than a qemu userspace app has to enable tun/tap networking.

:-Dustin

It is a bit poor to have qemu networking broken by default. I suggest the following in postinst:

setcap cap_net_admin=ep /usr/bin/qemu-system-*

For more information on QEMU and Linux capabilities see http://www.friedhoff.org/posixfilecaps.html

I'm sorry, this is not something that we can solve in the qemu-kvm package that is in Ubuntu Main.

You could, I suppose, submit a patch that adds another binary package under the qemu-kvm source package that we put in Universe.

I'm subscribing the Ubuntu Security team too.

Chris-

Thanks for your suggestion. I haven't tested it, yet. I've subscribed the Ubuntu Security Team. I'm curious for their opinion on this.

> I'm sorry, this is not something that we can solve in the qemu-kvm package that is in Ubuntu Main.

Why not? The standard Ubuntu kernel supports capabilities (CONFIG_SECURITY_FILE_CAPABILITIES). It is obviously not desirable to have qemu networking broken by default, or to tell users that they must run qemu as root if they want networking to work. I'd imagine that most people installing qemu would prefer that the qemu process be able to create a TUN/TAP device instead of returning some odd error message.

> You could, I suppose, submit a patch that adds another binary package under the qemu-kvm source package that we put in Universe.

It seems odd to create a new package just to fix networking for non-root users.

> I've subscribed the Ubuntu Security Team. I'm curious for their opinion on this.

From a security perspective, it is obviously better to give the qemu process a single relatively harmless capability than to require all users run qemu as root or suid root.

Marc/Kees/Jamie-

Would you care to answer the questions above? I've been telling people "no" for 4 Ubuntu releases that we will not enable tun/tap networking in qemu-kvm.

Please see https://help.ubuntu.com/community/KVM/Networking for a discussion of the issue. (Basically, it is unsafe to ship it this way as it gives any local user the ability to disrupt networking.)

Kees: I know about the wiki page - I'm the one who edited it to note this issue. It is not true that file capabilities only work in Lucid - I am using Karmic and it works fine. libcap2-bin is also not a PAM package. It is also not true that you need to manually add users to /etc/security/capability.conf. I will corrrect these points in the Wiki.

It is true that with CAP_NET_ADMIN capability any user could boot a VM and gain access to a virtual ethernet device. That's the whole point. I would assume that the majority of people installing qemu would actually want to be able to create bridged virtual ethernet devices. VirtualBox allows normal users to create bridged ethernet devices that could be used to "disrupt networking". Why should qemu be different? If you are concerned about users directly abusing the capability with their own software then this is not possible - giving the qemu binary the capability means that only that binary gets the capability - other binaries executed by the same user do not get the capability. Access to /dev/net/tun can still be controlled using standard file permissions as usual.

Using a file capability would obviously be preferable as it would not require individual users to be manually assigned the capability, and could be done in postinst and would survive qemu package upgrades. The only way someone could disrupt the network in this way is if they:

1) Were allowed to run qemu
2) Had rw access to /dev/net/tun
3) Had some exploit for qemu to allow them to run some arbitrary network disrupting code

Basically, whatever potential problems there are, the same problems are also present in VirtualBox, and yet that ships with working network bridging for VMs (the mechanism is different, but the fundamental problems are the same). Why can't qemu have working bridged networking? Why not create a "tun" group that has rw access to /dev/net/tun if that is the problem you are trying to avoid?

And if making the existing package work is unacceptable, then why not create a "qemu-kvm-working-bridged-networking" package and recommend that users who want bridged network use that instead?

It's very important to note that qemu-kvm is in Ubuntu main, and
VirtualBox is in universe. The quality control, and in particular the
security model you might expect are quite different between the two
packages in Ubuntu.

@Chris Yup, I understand how capabilities work. I'm actively working on getting fscaps functioning with Debian/Ubuntu packaging (see https://wiki.ubuntu.com/Security/FilesystemCapabilties). (You seemed to miss me changing "ep" to "ei" in the wiki -- I've added the old instructions back and clarified the procedure.)

Just because qemu claims to only work on tun/tap devices doesn't mean it can't be subverted into working on arbitrary network devices. In a perfect world, upstream qemu will create a helper tool that is uses fscaps, etc, and correctly manages the tun/tap devices before launching qemu itself. That reduces the exposure of CAP_NET_ADMIN and makes for a more auditable chunk of code.

I'll leave it up to the qemu maintainer in Ubuntu how to handle these things, but I just wanted to confirm that arbitrarily giving everyone CAP_NET_ADMIN (or being setuid root) via qemu was not preferred. If it's done via file permissions and a qemu-runners group, plus fscaps =ep, or done via fscaps =ei and select users are given =i via pam_cap, I don't much care. :)

Regardless, fscaps are not supported in Debian/Ubuntu packaging (which I very much want to fix), so this is all a non-issue until that is solved. In the meantime, I feel it is my responsibility to provide as safe a set of instructions that accomplishes the goal of accessing the tun/tap devices.

http://wiki.qemu.org/Features/HelperNetworking

We plan on addressing this upstream by introducing a helper to create the tap device. This helper would be owned by root, and would be limited in what it did with the tap device (in terms of attaching it to a bridge).

This allows a sysadmin to delegate an appropriate amount of privileges to non-privileged KVM users (but no more than what's necessary).

I've gone through this bug report as well as the relevant Debian Bug report and I don't think it's fixed.

The Debian bug appears to have been marked "Fix Released" because the actual qemu package was removed from Debian and replaced with qemu-kvm. Maybe another bug needs to be opened for that package.

Did this ever get fixed? The upstream patch with the helper was posted to the mailing list in November 2009 and in the same thread it is mentioned that the Ubuntu packaging would enable this by the time Lucid/qemu-0.12-rc1 was released.

http://<email address hidden>/msg17772.html

I assume the fix (as described in comment #14) is /etc/qemu-ifup ?