Re: [Qemu-discuss] Tap Devices

[Jakob Bohm]

On 11/30/2012 7:02 AM, Mike Lovell wrote:
> On 11/29/2012 01:59 PM, Frans de Boer wrote:
> > I have made the solution. Remember that OpenvSwitch is part of the 
> > issue. The part initializing OpenvSwitch is not discussed here, but I 
> > needed to take the next steps:
> >
> > Involved programs are: ifconfig, tunctl, ovs-vsctl.
> > These programs are set to system group 'qemu' (make it yourself)
> > The programs have the suid (sorry, not sgid!) bit set.
> > Also, /dev/net/tun has already the (default) 666 mode settings and 
> > there is no need to change the group from root to qemu.
>
> having ifconfig, tunctl, and ovs-vsctl all suid is probably a really 
> bad idea. that would allow anyone, or anything, on the system to 
> reconfigure the networking on the host without security checking and 
> possibly without the ability to know who made the changes.
>
> ...
> > qemu-system-x86_64 -machine type=pc,accel=kvm,kernel_irqchip=on 
> > --enable-kvm -cpu coreduo -smp 2 -vga std -soundhw ac97 -net 
> > tap,vlan=0,ifname=$sTAPID,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown 
> > -net nic,model=virtio,vlan=0,macaddr=52:54:00:00:FB:02 -m 2048 
> > -localtime -name VWinXP-nl -boot c -monitor vc:1680x1050 -usb 
> > -usbdevice tablet -alt-grab -drive 
> > file=/media/raidarray/vms/vwinxpnl.raw,index=0,media=disk,if=virtio,cache=writeback 
> > -no-frame -cdrom /dev/null
> >
> > The programs ifconfig and ovs-vsctl are used by the ovs-if[up|down] 
> > scripts when the tap device is initialized.
>
> do you use ifconfig, tunctl, or ovs-vsctl for operations other than 
> bring the tap interface up, creating a tap interface, and adding the 
> tap to the openvswitch bridge?
>
> if that is all you are using them for then it is possible to use 
> qemu-bridge-helper. without access to those utilities, it can create a 
> tap device, bring the interface up, and connect it to a bridge. the 
> potentially hard part is that the operation to connect the tap to the 
> bridge is through the standard bridge interface and so it wouldn't be 
> able to directly manipulate openvswitch. it is possible to do this 
> when also using the openvswitch brcompat module and daemon. these make 
> it so the standard bridge interfaces will manipulate openvswitch 
> bridges. see INSTALL.bridge in the openvswitch source for setting it up.
>
> i set up openvswitch on a box i had laying around and got the brcompat 
> support working. after doing that, i was able to use openvswitch with 
> the qemu-bridge-helper. 'qemu-system-x86_64 -net nic -net 
> bridge,helper=/usr/lib/qemu-bridge-helper,br=br0' was able to start a 
> vm and checking 'ovs-vsctl list-ports br0' showed a new tap device 
> connected to the openvswitch bridge.
>
> if the scripts you are using do more than just creating the tap 
> interface, connecting it to the bridge, and bringing up the interface 
> then the qemu-bridge-helper probably wouldn't work as is. if that is 
> case, i would recommend writing some set of scripts that include sudo 
> and adding the sudo commands to sudoers. something like this might work
>
> #qemu-ifup
> sudo ifconfig $1 0.0.0.0 up
> sudo ovs-vsctl add-port $BRIDGE $1
>
> #qemu-ifdown
> sudo ifconfig $1 0.0.0.0 down
> sudo ovs-vsctl del-port $BRIDGE $1
>
> #!/bin/sh
> USER=`whoami`
> sTAPID=`sudo tunctl -b -u $USER`
> qemu-system-x86_64 -machine type=pc,accel=kvm,kernel_irqchip=on 
> --enable-kvm -cpu coreduo -smp 2 -vga std -soundhw ac97 -net 
> tap,vlan=0,ifname=$sTAPID,script=sudo-ovs-ifup,downscript=sudo-ovs-ifdown 
> -net nic,model=virtio,vlan=0,macaddr=52:54:00:00:FB:02 -m 2048 
> -localtime -name VWinXP-nl -boot c -monitor vc:1680x1050 -usb 
> -usbdevice tablet -alt-grab -drive 
> file=/media/raidarray/vms/vwinxpnl.raw,index=0,media=disk,if=virtio,cache=writeback 
> -no-frame -cdrom /dev/null
>
> then add something like "%qemu ALL= NOPASSWD: 
> /sbin/ifconfig,/usr/bin/ovs-vsctl,/usr/sbin/tunctl " in sudoers. i 
> just typed this in the email and not tested so typos or slight errors 
> might exist but the general idea should work.
There is also the "super" program which is more tailored to this kind of 
situation.

"super" is a suid binary which consults a global "super.tab" file 
listing virtual commands such as "qemu-ifup", specifies what real users 
can call it and what real command to execute as which user and in which 
environment.  Unlike sudo, there is no "type your password again" 
prompting, security is assured by more strictly limiting who can do what 
and not having a general shell as a default option.  If you symlink 
/usr/local/bin/qemu-ifdown to /usr/bin/super, when non-root runs 
"qemu-ifdown", this gets mapped to the "qemu-ifdown" entry in super.tab, 
which then determines the rules and script to run.

> ...


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded