[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qem

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 17:05:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

On 11/05/2009 04:50 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 11/05/2009 04:33 PM, Avi Kivity wrote:
and concerned that we're loosening security for qemu non-users.

I see you've addressed this via an acl system. Still, this is IMO should be outside qemu, esp. as security is now much more than users/groups (i.e. selinux and friends).

Actually, I think this model is pretty close to what the latest crazes are in the security world.

I think we need to isolate qemu for these crazes. First, we're hardly security experts here. Second, anything we do will be bad for someone. Third, security models vary across distributions and time.

The model you're advocating (privileged process handing over a fd) is not as secure because it requires that the management daemon runs as a privileged user.

Or it can acquire an fd from a privileged helper and pass it on or conjure it some other way.

There's nothing about this that prevents the use of a management framework. In fact, had this existed when libvirt was first written, I'd hope libvirt would have used this mechanism instead of fd inheritance.

Management software is really just another user. We really want management software to run unprivileged as much as possible.

I'd like to see qemu confined to managing a single guest and not expand to system management. We have enough to do without taking over management systems and security.

Bridged network configuration is painful now, but only for a handful of users (us developers). For the vast majority it is handled behind their back by management, which has to deal with a bunch of privileged stuff anyway (assigned LVM volumes, assigned pci and usb devices, setting up the bridge, large pages, guest priorities). Why are we adding code to benefit so few people, many of whom don't really use qemu as users?

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]