Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 27, 2010 at 11:36:31AM -0600, Anthony Liguori wrote:
> On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:
>>>   In this case, the full
>>> syntax would be:
>>>
>>> -net vepa,if=eth0
>>>
>>> or
>>>
>>> -net vepa,fd=N
>>>      
>> I still hope it's extbridge, vepa is an acronym that will likely not be
>> known for 99% of users.
>>    
>
> Oh sorry, I don't care about the name at all.  If you prefer extbridge,  
> I'm all for it :-)
>
>>> where N is a macvtap fd.
>>>
>>> For raw, I think there's a real problem wrt security.  I think it's
>>> important that we support running qemu as a non-privileged user.  In
>>> fact, this seems to be the mode libvirt is now preferring to operate in.
>>>
>>> I think we need to re-evaluate the use of any raw socket by qemu as it's
>>> very dangerous from a security perspective (assuming we cannot
>>> introduced a "locked" raw socket mode).
>>>      
>> As was pointed out on netdev and elsewhere this seems to be what
>> namespaces/selinux are there for. Can qemu be run within a namespace and
>> if yes would that address your concerns?
>
> It's unclear to me what this would even involve.  But really, we just  
> want an interface to inject packets directly into a physical device.   

Not only. We also want to program filters by mac/vlan, enable/disable
promisc mode, set mac, maybe more, all this in response to guest
activity so it's not as trivial as doing it in a helper script.  The
patches supplied do not do this and do filtering in userspace but I
trust this is short-term.

> raw sockets give us that but it also gives us way more.  Using network  
> namespaces to restrict this is a bit convoluted.  It seems to me that  
> providing an interface that never gives us way more to start with is  
> better overall from a security perspective.

You are thinking about qemu security so custom groups and permissions on
character devices and/or suid scripts with custom configuration files
look nice to you.  But think in terms of an overall system security. If
you write custom kernel interfaces you end up with an unmanageable
security policy. And system administrator not being in control of
security policy is very bad for security.

All the above is basically repeating what others said on netdev.
If you care, pls argue on disablenetwork thread.

> Regards,
>
> Anthony Liguori
>
>>    Security is probably a wrong
>> reason to use character devices: they are much more likely to have
>> security problems than standard interfaces.  Ease of setup/compatibility
>> with tap would be a better reason.
>>
>>    
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>      
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>>>
>>>>>