From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GZo4b-000573-H9 for qemu-devel@nongnu.org; Tue, 17 Oct 2006 08:29:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GZo4Z-00054a-KG for qemu-devel@nongnu.org; Tue, 17 Oct 2006 08:29:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GZo4Y-00053h-Ub for qemu-devel@nongnu.org; Tue, 17 Oct 2006 08:29:31 -0400 Received: from [64.233.182.188] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GZoDu-0004qS-0X for qemu-devel@nongnu.org; Tue, 17 Oct 2006 08:39:10 -0400 Received: by nf-out-0910.google.com with SMTP id p46so390324nfa for ; Tue, 17 Oct 2006 05:29:29 -0700 (PDT) Message-ID: Date: Tue, 17 Oct 2006 14:29:28 +0200 From: "G Portokalidis" Subject: Re: [Qemu-devel] qemu and kernel 2.6.18 In-Reply-To: <20061016103648.8f2dfe23.chris@friedhoff.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_116252_2855064.1161088168930" References: <9b0d5f320610131000x744ce6cagd549f4ec0e1ac9f7@mail.gmail.com> <20061014094706.a59e3e33.chris@friedhoff.org> <92c265230610150031h570a1cfenedc723b9a9949a25@mail.gmail.com> <20061016103648.8f2dfe23.chris@friedhoff.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_116252_2855064.1161088168930 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I thought the best way to overcome the restriction imposed in tun/tap interfaces is to set qemu as suid, and revoke privileges as soon as the network interfaces are configured, and before any virtual block devices are opened. I wrote this little patch, which hopefully does just that. Cheers, George On 16/10/06, chris friedhoff wrote: > Hi, > > checking the Changelog for 2.6.18 (and diffing) one can see, that the CAP_NET_ADMIN requirement was added for the tun/tap inerface in tun.c. The question is, is it acceptable for a user to add a tun/tap interface in a running system. It was before 2.6.18. A different approach is, to grant the user or the process the CAP_NET_ADMIN capabillity. > If the user of the system running qemu is in control of the system, he might start qemu as root. The tun/tap interface is created (due to root-rights), but i wouldn't like to see windows running in a root started qemu. > Running qemu with kqemu, you need to be able to modprobe kqemu in a root context. If a user has the right to modprobe a module, he can do anything. What might be critical is that a user-context started app might create also a tun/tap interface (for evil reason) without the knowledge of the user. But than one has to ask, what kind of software is he running. > But nevertheless, if you patch the kernel, you have to know what you do ... > > The changelog: http://lwn.net/Articles/190305/ (search for tuntap) > > Chris > > ######################################## > > On Sun, 15 Oct 2006 15:31:11 +0800 > Tace wrote: > > > Hi, > > That might be some security issues with removal of that capability > > check. I think it is not a good idea to remove it. > > > > 2006/10/14, chris friedhoff : > > > Hello, > > > > > > bringing up the tun/tap interface depends now on the capability CAP_NET_ADMIN, which usually only root has. > > > This patch just removes this dependency, so normal user rights suffices again to bring up the tun/tap interface. > > > > > > diff -ruN linux-2.6.18-orig/drivers/net/tun.c linux-2.6.18/drivers/net/tun.c > > > --- linux-2.6.18-orig/drivers/net/tun.c 2006-09-20 05:42:06.000000000 +0200 > > > +++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.000000000 +0200 > > > @@ -489,9 +489,6 @@ > > > > > > err = -EINVAL; > > > > > > - if (!capable(CAP_NET_ADMIN)) > > > - return -EPERM; > > > - > > > /* Set dev type */ > > > if (ifr->ifr_flags & IFF_TUN) { > > > /* TUN device */ > > > > > -------------------- > Chris Friedhoff > chris@friedhoff.org > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ------=_Part_116252_2855064.1161088168930 Content-Type: application/octet-stream; name=qemu-0.8.2-linux-2.6.18.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_ete9w2f5 Content-Disposition: attachment; filename="qemu-0.8.2-linux-2.6.18.patch" ZGlmZiAtTnVhciBxZW11LTAuOC4yL01ha2VmaWxlLnRhcmdldCBxZW11LTAuOC4yLWxpbnV4LTIu Ni4xOC9NYWtlZmlsZS50YXJnZXQKLS0tIHFlbXUtMC44LjIvTWFrZWZpbGUudGFyZ2V0CTIwMDYt MDctMjIgMTk6MjM6MzQuMDAwMDAwMDAwICswMjAwCisrKyBxZW11LTAuOC4yLWxpbnV4LTIuNi4x OC9NYWtlZmlsZS50YXJnZXQJMjAwNi0xMC0xNyAxNDoyMDo0MS4wMDAwMDAwMDAgKzAyMDAKQEAg LTUzMCw3ICs1MzAsNyBAQAogCiBpbnN0YWxsOiBhbGwgCiBpZm5lcSAoJChQUk9HUyksKQotCSQo SU5TVEFMTCkgLW0gNzU1IC1zICQoUFJPR1MpICIkKERFU1RESVIpJChiaW5kaXIpIgorCSQoSU5T VEFMTCkgLW0gNDc1NSAtcyAkKFBST0dTKSAiJChERVNURElSKSQoYmluZGlyKSIKIGVuZGlmCiAK IGlmbmVxICgkKHdpbGRjYXJkIC5kZXBlbmQpLCkKZGlmZiAtTnVhciBxZW11LTAuOC4yL3ZsLmMg cWVtdS0wLjguMi1saW51eC0yLjYuMTgvdmwuYwotLS0gcWVtdS0wLjguMi92bC5jCTIwMDYtMDct MjIgMTk6MjM6MzQuMDAwMDAwMDAwICswMjAwCisrKyBxZW11LTAuOC4yLWxpbnV4LTIuNi4xOC92 bC5jCTIwMDYtMTAtMTcgMTQ6MTQ6NDkuMDAwMDAwMDAwICswMjAwCkBAIC02MDY5LDYgKzYwNjks MTAgQEAKICAgICAgICAgICAgIGV4aXQoMSk7CiAgICAgfQogCisgICAgLyogUmV2b2tlIHByaXZp bGVnZXMgaGVyZS4gUmVhbCB1c2VyIHN0aWxsIG5lZWRzIHRvIGhhdmUgcGVybWlzc2lvbnMgb24K KyAgICAgKiBibG9jayBkZXZzICovCisgICAgc2V0dWlkKGdldHVpZCgpKTsKKwogICAgIC8qIGlu aXQgdGhlIG1lbW9yeSAqLwogICAgIHBoeXNfcmFtX3NpemUgPSByYW1fc2l6ZSArIHZnYV9yYW1f c2l6ZSArIGJpb3Nfc2l6ZTsKIAo= ------=_Part_116252_2855064.1161088168930--