[libvirt] Using Generic Ethernet type with custom networking without lowering the host security level

[Ishimoto, Ryu]

Hi Laine,

On Tue, Nov 6, 2012 at 3:30 AM, Laine Stump <laine at laine.org> wrote:

>
> I've only used type='ethernet' to verify that it worked, so don't have a
> very good database of potential usage scenarios and whether or not what
> I suggest below would work for all of them, so my advice here is suspect
> :-) However, this is what I notice:
>
> On the qemu commandline, both type='bridge' (I'll leave out
> type='network' from now on, as it's essentially identical to bridge for
> this discussion) and type='ethernet' add a "tap" argument to the qemu
> command line, but in one case we create/open a tap device and sent the
> fd to qemu with
>
>    -netdev tap,fd=nn,...
>
> and in the other, we just blindly send the name of the tap device, as
> well as script parameter (if requested) and allow qemu to open it:
>
>    -netdev tap,ifname=/dev/mytapX,script=/etc/libvirt/myscript,...
>
> It *looks* like (from the "qemu-kvm -help" output) we could just as
> easily open that tap device in libvirt, and send "-netdev
> tap,fd=nn,script=/etc/libvirt/myscript,..." to qemu (or, when no script
> is specified, just "-netdev tap,fd=nn,...".


After briefly looking at the qemu code, it looks like qemu does not like it
when you send both fd and script.  It requires that you send the device
name if script is specified.  But this isn't a problem as libvirt would
have no problem figuring out whether it should send fd or device name.


>
> If this is true (any qemu people who can tell me for sure?), simply
> changing the code for type='ethernet' in this manner would solve your
> problem - you would make sure that:
>
> 1) your <interface> is "type='ethernet'"
> 2) your tap device has a name ("<target dev='xxx'/>") that doesn't start
> with "vnet", *and*
> 3) that device is created and attached to the proper place beforehand
>
> libvirt would then open the provided tap device and pass it to qemu,
> with no other action performed. Because it would be passing an open fd
> to qemu (instead of a tap device name) and because there would be no
> script involved, no decreased security level would be required for qemu.
>
>
This is precisely the solution that I was looking for :-)  With this
solution, if the device name is specified(that does not start with 'vnet'),
libvirt will try to open the device with this name, and if the device does
not exist, it would create a new one, and if it already exists, it would
attach to it.  Either way, libvirt has access to its fd which would be
passed over to qemu, allowing it to run without fiddling around with its
privilege level.


> As far as running a user-specified script, currently we leave it up to
> qemu to do this; perhaps we should have an attribute for type='ethernet'
> that indicates libvirt should execute the script instead? (maybe the
> choice of sending tap device name vs fd to qemu should be controlled by
> the same attribute that controls whether libvirt or qemu executes the up
> script.
>
> (and btw, there's an open request to support the "down script" that qemu
> supports).
>
>
One possible implementation could be that we introduce a 'secure' attribute
for generic ethernet where if set to true, libvirt runs the script instead
of qemu.


>
> Would what I outlined above work? (modify type='ethernet' to open the
> given tap device and send its fd rather than name + optionally executing
> the script in libvirt rather than passing it to qemu)
>
>
Yes, your solution does work for me.  Thanks for your helpful comments.  As
a first step, I think libvirt should implement the logic in which it opens
an existing device and pass its fd to qemu if script is not
specified(instead of always passing the device name).  This should
eliminate the security concerns for cases in which no script needs to run.
 And the second step is to handle the script execution logic where libvirt
could optionally handle the execution of the script.  Does that sound
reasonable?

Ryu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121107/8987c95c/attachment-0001.htm>