Ubuntu

qemu no tun/tap networking

Reported by Rolf Offermanns on 2007-04-04
50
This bug affects 8 people
Affects Status Importance Assigned to Milestone
qemu (Ubuntu)
Wishlist
Unassigned
qemu-kvm (Debian)
Fix Released
Unknown
qemu-kvm (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: qemu

There is a problem with qemu and kernels > 2.6.18.

It is documented in the qemu faq:
Starting with Linux 2.6.18, the kernel now requires that a user process has CAP_NET_ADMIN capability associated with it to set persistent tap interfaces. This a problem since most people do not run qemu as root - nor should they. A few suggestions: [...]
http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-2511814cb92c14dbe1480089c04f83c281117a86

The problem looks like this:
"warning: could not open /dev/net/tun: no virtual network emulation
Could not initialize device 'tap'"

# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 Mar 30 08:19 /dev/net/tun

Solutions are suggested in the FAQ entry.

Problem persists in qemu 0.9.0.

Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 beta?

Changed in qemu:
status: New → Incomplete
Pedro Villavicencio (pedro) wrote :

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!.

Changed in qemu:
status: Incomplete → Invalid
Roland Hieber (rohieb) wrote :

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

Changed in qemu:
status: Invalid → New
Dustin Kirkland  (kirkland) wrote :

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

Changed in qemu (Ubuntu):
status: New → Won't Fix

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

Changed in qemu (Ubuntu):
status: Won't Fix → Confirmed
Dustin Kirkland  (kirkland) wrote :

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.

Changed in qemu (Ubuntu):
status: Confirmed → Invalid
status: Invalid → Won't Fix
Changed in qemu-kvm (Ubuntu):
status: New → Won't Fix
Changed in qemu (Ubuntu):
importance: Undecided → Wishlist
Changed in qemu-kvm (Ubuntu):
importance: Undecided → Wishlist
Dustin Kirkland  (kirkland) wrote :

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.

Dustin Kirkland  (kirkland) wrote :

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.

Changed in qemu-kvm (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Kees Cook (kees) wrote :

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.)

Changed in qemu-kvm (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody

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.

Kees Cook (kees) wrote :

@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).

Changed in qemu-kvm (Debian):
status: Unknown → Fix Released
George Politis (gpolitis) wrote :

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

Serge Hallyn (serge-hallyn) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.