Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Ben Taylor]

---- "Kevin F. Quinn" <ml@kevquinn.com> wrote: 
> On Fri, 9 Feb 2007 22:48:51 +0000
> Paul Brook <paul@codesourcery.com> wrote:
> 
> > I've very little sympathy (read: none) for people who "accidentally"
> > break things by running them as root.
> 
> On a related note, I've been running qemu(-system 0.8.2) as root
> recently as a hopefully temporary measure so that it can setup the
> network interfaces.  Recent linux kernels require CAP_NET_ADMIN for the
> tun network configuration that qemu does (specifically the TUNSETIFF
> ioctl), and the only way to get the capability is to start the process
> as root.
> 
> Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once
> the network configuration is done, but that means modifications to qemu
> itself to release the capabilities, and would still leave qemu as a
> suid-root binary, which it would be nicer to avoid.
> 
> Is there any way around this?  I expected to be able to configure
> capabilities for executables in the filesystem, but it appears there
> are serious problems with that concept so the kernel doesn't support
> it.

I just dealt with that.  I got a patch for tap for Solaris and I have a setuid script
that creates the tap and uses the /etc/qemu-ifup script to configure the interface,
then calls a script with the file descriptor of the tap interface to a script which
then invokes qemu with the right parameteres.

Ben

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Chris Friedhoff]

Have a look here with links and a description:
http://www.friedhoff.org/fscaps.html
http://www.friedhoff.org/fscaps.html#Qemu

Serges patch is in the mm tree.

Chris


On Sat, 10 Feb 2007 15:11:00 +0000
Paul Brook <paul@codesourcery.com> wrote:

> > Is there any way around this?  I expected to be able to configure
> > capabilities for executables in the filesystem, but it appears there
> > are serious problems with that concept so the kernel doesn't support
> > it.
> 
> Use tunctl to create the device.
> 
> Paul
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


--------------------
Chris Friedhoff
chris@friedhoff.org

Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Paul Brook]

> Is there any way around this?  I expected to be able to configure
> capabilities for executables in the filesystem, but it appears there
> are serious problems with that concept so the kernel doesn't support
> it.

Use tunctl to create the device.

Paul

CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Fri, 9 Feb 2007 22:48:51 +0000
Paul Brook <paul@codesourcery.com> wrote:

> I've very little sympathy (read: none) for people who "accidentally"
> break things by running them as root.

On a related note, I've been running qemu(-system 0.8.2) as root
recently as a hopefully temporary measure so that it can setup the
network interfaces.  Recent linux kernels require CAP_NET_ADMIN for the
tun network configuration that qemu does (specifically the TUNSETIFF
ioctl), and the only way to get the capability is to start the process
as root.

Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once
the network configuration is done, but that means modifications to qemu
itself to release the capabilities, and would still leave qemu as a
suid-root binary, which it would be nicer to avoid.

Is there any way around this?  I expected to be able to configure
capabilities for executables in the filesystem, but it appears there
are serious problems with that concept so the kernel doesn't support
it.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]