On Wed, 2010-01-27 at 11:36 -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. > 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. I too think that we should not block raw backend in qemu just because of security reasons. It should be perfectly fine to use raw backend in scenarios where qemu can be run as a privileged process. libvirt need not support raw backend until we figure out a secure way to start qemu when passing raw fd. using network namespaces seems like a good option. Thanks Sridhar -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
