* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
[not found] <1345068639-19528-1-git-send-email-mhcerri@linux.vnet.ibm.com>
@ 2012-09-11 18:13 ` Corey Bryant
2012-09-13 20:36 ` Marcelo Cerri
2012-09-14 8:40 ` Daniel P. Berrange
0 siblings, 2 replies; 6+ messages in thread
From: Corey Bryant @ 2012-09-11 18:13 UTC (permalink / raw
To: berrange, mprivozn
Cc: Anthony Liguori, bryntcor, libvir-list, Marcelo Cerri, qemu-devel,
gcwilson, eblake
Are there any other requirements that need to be taken care of to enable
execution of QEMU guests under separate unprivileged user IDs (ie. DAC
isolation)?
At this point, this patch series (Per-guest configurable user/group for
QEMU processes) is upstream, allowing libvirt to execute guests under
separate unprivileged user IDs. Additionally, the QEMU bridge helper
series is upstream, allowing QEMU to allocate a tap device and attach it
to a bridge when run under an unprivileged user ID
(http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
Is there any other feature in QEMU that requires QEMU to be run as root?
--
Regards,
Corey
On 08/15/2012 06:10 PM, Marcelo Cerri wrote:
> This is a v4 patch series that updates the libvirt's security driver mechanism to support per-guest configurable user and group for QEMU processes running together with other security drivers, such as SELinux and AppArmor.
>
> Marcelo Cerri (5):
> Internal refactory of data structures
> Multiple security drivers in XML data
> Update security layer to handle many security labels
> Support for multiple default security drivers in QEMU config
> Update the remote API
>
> daemon/remote.c | 63 ++++
> docs/formatdomain.html.in | 11 +-
> docs/schemas/capability.rng | 18 +-
> docs/schemas/domaincommon.rng | 30 ++-
> include/libvirt/libvirt.h.in | 2 +
> python/generator.py | 1 +
> src/conf/capabilities.c | 17 +-
> src/conf/capabilities.h | 6 +-
> src/conf/domain_audit.c | 14 +-
> src/conf/domain_conf.c | 343 +++++++++++++++-----
> src/conf/domain_conf.h | 20 +-
> src/driver.h | 4 +
> src/libvirt.c | 47 +++
> src/libvirt_private.syms | 5 +
> src/libvirt_public.syms | 1 +
> src/lxc/lxc_conf.c | 8 +-
> src/lxc/lxc_controller.c | 8 +-
> src/lxc/lxc_driver.c | 11 +-
> src/lxc/lxc_process.c | 23 +-
> src/qemu/qemu.conf | 6 +-
> src/qemu/qemu_conf.c | 38 ++-
> src/qemu/qemu_conf.h | 2 +-
> src/qemu/qemu_driver.c | 218 +++++++++++---
> src/qemu/qemu_process.c | 50 ++-
> src/remote/remote_driver.c | 46 +++
> src/remote/remote_protocol.x | 17 +-
> src/remote_protocol-structs | 11 +
> src/security/security_apparmor.c | 118 +++++--
> src/security/security_dac.c | 324 +++++++++++++++++--
> src/security/security_manager.c | 101 +++++--
> src/security/security_manager.h | 8 +-
> src/security/security_selinux.c | 263 +++++++++++-----
> src/security/security_stack.c | 237 +++++++++-----
> src/security/security_stack.h | 13 +
> src/test/test_driver.c | 11 +-
> .../qemuxml2argv-seclabel-dynamic-override.xml | 4 +-
> .../qemuxml2argv-seclabel-dynamic.xml | 2 +-
> 37 files changed, 1653 insertions(+), 448 deletions(-)
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
2012-09-11 18:13 ` [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes Corey Bryant
@ 2012-09-13 20:36 ` Marcelo Cerri
2012-09-14 8:40 ` Daniel P. Berrange
1 sibling, 0 replies; 6+ messages in thread
From: Marcelo Cerri @ 2012-09-13 20:36 UTC (permalink / raw
To: berrange, mprivozn, libvir-list, eblake, qemu-devel,
Anthony Liguori, Daniel Veillard
Cc: Corey Bryant, gcwilson, bryntcor
Hi,
Any comments about that?
Regards,
Marcelo
On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
> Are there any other requirements that need to be taken care of to
> enable execution of QEMU guests under separate unprivileged user IDs
> (ie. DAC isolation)?
>
> At this point, this patch series (Per-guest configurable user/group
> for QEMU processes) is upstream, allowing libvirt to execute guests
> under separate unprivileged user IDs. Additionally, the QEMU bridge
> helper series is upstream, allowing QEMU to allocate a tap device
> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
>
> Is there any other feature in QEMU that requires QEMU to be run as root?
>
> --
> Regards,
> Corey
>
> On 08/15/2012 06:10 PM, Marcelo Cerri wrote:
> >This is a v4 patch series that updates the libvirt's security driver mechanism to support per-guest configurable user and group for QEMU processes running together with other security drivers, such as SELinux and AppArmor.
> >
> >Marcelo Cerri (5):
> > Internal refactory of data structures
> > Multiple security drivers in XML data
> > Update security layer to handle many security labels
> > Support for multiple default security drivers in QEMU config
> > Update the remote API
> >
> > daemon/remote.c | 63 ++++
> > docs/formatdomain.html.in | 11 +-
> > docs/schemas/capability.rng | 18 +-
> > docs/schemas/domaincommon.rng | 30 ++-
> > include/libvirt/libvirt.h.in | 2 +
> > python/generator.py | 1 +
> > src/conf/capabilities.c | 17 +-
> > src/conf/capabilities.h | 6 +-
> > src/conf/domain_audit.c | 14 +-
> > src/conf/domain_conf.c | 343 +++++++++++++++-----
> > src/conf/domain_conf.h | 20 +-
> > src/driver.h | 4 +
> > src/libvirt.c | 47 +++
> > src/libvirt_private.syms | 5 +
> > src/libvirt_public.syms | 1 +
> > src/lxc/lxc_conf.c | 8 +-
> > src/lxc/lxc_controller.c | 8 +-
> > src/lxc/lxc_driver.c | 11 +-
> > src/lxc/lxc_process.c | 23 +-
> > src/qemu/qemu.conf | 6 +-
> > src/qemu/qemu_conf.c | 38 ++-
> > src/qemu/qemu_conf.h | 2 +-
> > src/qemu/qemu_driver.c | 218 +++++++++++---
> > src/qemu/qemu_process.c | 50 ++-
> > src/remote/remote_driver.c | 46 +++
> > src/remote/remote_protocol.x | 17 +-
> > src/remote_protocol-structs | 11 +
> > src/security/security_apparmor.c | 118 +++++--
> > src/security/security_dac.c | 324 +++++++++++++++++--
> > src/security/security_manager.c | 101 +++++--
> > src/security/security_manager.h | 8 +-
> > src/security/security_selinux.c | 263 +++++++++++-----
> > src/security/security_stack.c | 237 +++++++++-----
> > src/security/security_stack.h | 13 +
> > src/test/test_driver.c | 11 +-
> > .../qemuxml2argv-seclabel-dynamic-override.xml | 4 +-
> > .../qemuxml2argv-seclabel-dynamic.xml | 2 +-
> > 37 files changed, 1653 insertions(+), 448 deletions(-)
> >
> >--
> >libvir-list mailing list
> >libvir-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/libvir-list
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
2012-09-11 18:13 ` [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes Corey Bryant
2012-09-13 20:36 ` Marcelo Cerri
@ 2012-09-14 8:40 ` Daniel P. Berrange
2012-09-14 13:31 ` Corey Bryant
1 sibling, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2012-09-14 8:40 UTC (permalink / raw
To: Corey Bryant
Cc: Anthony Liguori, bryntcor, libvir-list, mprivozn, qemu-devel,
eblake, gcwilson, Marcelo Cerri
On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
> Are there any other requirements that need to be taken care of to
> enable execution of QEMU guests under separate unprivileged user IDs
> (ie. DAC isolation)?
>
> At this point, this patch series (Per-guest configurable user/group
> for QEMU processes) is upstream, allowing libvirt to execute guests
> under separate unprivileged user IDs. Additionally, the QEMU bridge
> helper series is upstream, allowing QEMU to allocate a tap device
> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
>
> Is there any other feature in QEMU that requires QEMU to be run as root?
Well those features you mention are for two separate issues. When
running libvirt privileged (qemu:///system), QEMU was already run
as non-root (qemu:qemu). The per-guest user/group was just making
sure that QEMU VMs were isolated from each other using user IDs.
Since libvirtd is running privileged, it can either set permissions
or open things on QEMU's behalf. All this side of things really
works already.
The TAP device bridge helper is something that's needed when running
libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
In this case libvirtd can't access privileged resources at all, hence
the setuid TAP helper was required.
So I guess this is a roundabout way of saying that I'm not really
clear what you're asking about ? If you're using qemu:///system
there has never been any problem with running QEMU unprivileged.
When using qemu:///session you're obviously limited to whatever
resources the user is allowed to access.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
2012-09-14 8:40 ` Daniel P. Berrange
@ 2012-09-14 13:31 ` Corey Bryant
2012-09-14 13:51 ` Daniel P. Berrange
0 siblings, 1 reply; 6+ messages in thread
From: Corey Bryant @ 2012-09-14 13:31 UTC (permalink / raw
To: Daniel P. Berrange
Cc: Anthony Liguori, bryntcor, libvir-list, mprivozn, qemu-devel,
Marcelo Cerri, gcwilson, eblake
On 09/14/2012 04:40 AM, Daniel P. Berrange wrote:
> On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
>> Are there any other requirements that need to be taken care of to
>> enable execution of QEMU guests under separate unprivileged user IDs
>> (ie. DAC isolation)?
>>
>> At this point, this patch series (Per-guest configurable user/group
>> for QEMU processes) is upstream, allowing libvirt to execute guests
>> under separate unprivileged user IDs. Additionally, the QEMU bridge
>> helper series is upstream, allowing QEMU to allocate a tap device
>> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
>>
>> Is there any other feature in QEMU that requires QEMU to be run as root?
>
> Well those features you mention are for two separate issues. When
> running libvirt privileged (qemu:///system), QEMU was already run
> as non-root (qemu:qemu). The per-guest user/group was just making
> sure that QEMU VMs were isolated from each other using user IDs.
> Since libvirtd is running privileged, it can either set permissions
> or open things on QEMU's behalf. All this side of things really
> works already.
Ok good. This is really what I was getting at and you answered my
question. So we now have DAC isolation of QEMU guests when running with
the qemu:///system URI and there shouldn't be any issues running
unprivileged guests from a privileged libvirt.
>
> The TAP device bridge helper is something that's needed when running
> libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
> In this case libvirtd can't access privileged resources at all, hence
> the setuid TAP helper was required.
>
Ah, that's right, the bridge helper is really only benefiting libvirt
when running with the qemu:///session URI.
Is there a desire to get to a point where libvirt can do everything
under a session URI that it can do today under a system URI? Then
libvirt and guests could all run unprivileged. I'm sure it's a lot of
work.. I'm just asking. :)
> So I guess this is a roundabout way of saying that I'm not really
> clear what you're asking about ? If you're using qemu:///system
> there has never been any problem with running QEMU unprivileged.
> When using qemu:///session you're obviously limited to whatever
> resources the user is allowed to access.
--
Regards,
Corey Bryant
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
2012-09-14 13:31 ` Corey Bryant
@ 2012-09-14 13:51 ` Daniel P. Berrange
2012-09-14 14:44 ` Corey Bryant
0 siblings, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2012-09-14 13:51 UTC (permalink / raw
To: Corey Bryant
Cc: Anthony Liguori, bryntcor, libvir-list, mprivozn, qemu-devel,
Marcelo Cerri, gcwilson, eblake
On Fri, Sep 14, 2012 at 09:31:26AM -0400, Corey Bryant wrote:
>
>
> On 09/14/2012 04:40 AM, Daniel P. Berrange wrote:
> >On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
> >>Are there any other requirements that need to be taken care of to
> >>enable execution of QEMU guests under separate unprivileged user IDs
> >>(ie. DAC isolation)?
> >>
> >>At this point, this patch series (Per-guest configurable user/group
> >>for QEMU processes) is upstream, allowing libvirt to execute guests
> >>under separate unprivileged user IDs. Additionally, the QEMU bridge
> >>helper series is upstream, allowing QEMU to allocate a tap device
> >>and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
> >>
> >>Is there any other feature in QEMU that requires QEMU to be run as root?
> >
> >Well those features you mention are for two separate issues. When
> >running libvirt privileged (qemu:///system), QEMU was already run
> >as non-root (qemu:qemu). The per-guest user/group was just making
> >sure that QEMU VMs were isolated from each other using user IDs.
> >Since libvirtd is running privileged, it can either set permissions
> >or open things on QEMU's behalf. All this side of things really
> >works already.
>
> Ok good. This is really what I was getting at and you answered my
> question. So we now have DAC isolation of QEMU guests when running
> with the qemu:///system URI and there shouldn't be any issues
> running unprivileged guests from a privileged libvirt.
>
> >
> >The TAP device bridge helper is something that's needed when running
> >libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
> >In this case libvirtd can't access privileged resources at all, hence
> >the setuid TAP helper was required.
> >
>
> Ah, that's right, the bridge helper is really only benefiting
> libvirt when running with the qemu:///session URI.
>
> Is there a desire to get to a point where libvirt can do everything
> under a session URI that it can do today under a system URI? Then
> libvirt and guests could all run unprivileged. I'm sure it's a lot
> of work.. I'm just asking. :)
Well if you want to give a VM a raw block device someone/thing needs to
be running privileged to set an ACL on the device to le the unprivileged
VM use it. Similarly for PCI device passthrough. Traditionally in the
qemu:///system case, libvirt can deal with this. In a qemu:///session
case the sysadmin would have had to setup ACLs/permissions on the
devices / files ahead of time.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
2012-09-14 13:51 ` Daniel P. Berrange
@ 2012-09-14 14:44 ` Corey Bryant
0 siblings, 0 replies; 6+ messages in thread
From: Corey Bryant @ 2012-09-14 14:44 UTC (permalink / raw
To: Daniel P. Berrange
Cc: Anthony Liguori, libvir-list, mprivozn, qemu-devel, eblake,
gcwilson, Marcelo Cerri
On 09/14/2012 09:51 AM, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 09:31:26AM -0400, Corey Bryant wrote:
>>
>>
>> On 09/14/2012 04:40 AM, Daniel P. Berrange wrote:
>>> On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
>>>> Are there any other requirements that need to be taken care of to
>>>> enable execution of QEMU guests under separate unprivileged user IDs
>>>> (ie. DAC isolation)?
>>>>
>>>> At this point, this patch series (Per-guest configurable user/group
>>>> for QEMU processes) is upstream, allowing libvirt to execute guests
>>>> under separate unprivileged user IDs. Additionally, the QEMU bridge
>>>> helper series is upstream, allowing QEMU to allocate a tap device
>>>> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
>>>>
>>>> Is there any other feature in QEMU that requires QEMU to be run as root?
>>>
>>> Well those features you mention are for two separate issues. When
>>> running libvirt privileged (qemu:///system), QEMU was already run
>>> as non-root (qemu:qemu). The per-guest user/group was just making
>>> sure that QEMU VMs were isolated from each other using user IDs.
>>> Since libvirtd is running privileged, it can either set permissions
>>> or open things on QEMU's behalf. All this side of things really
>>> works already.
>>
>> Ok good. This is really what I was getting at and you answered my
>> question. So we now have DAC isolation of QEMU guests when running
>> with the qemu:///system URI and there shouldn't be any issues
>> running unprivileged guests from a privileged libvirt.
>>
>>>
>>> The TAP device bridge helper is something that's needed when running
>>> libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
>>> In this case libvirtd can't access privileged resources at all, hence
>>> the setuid TAP helper was required.
>>>
>>
>> Ah, that's right, the bridge helper is really only benefiting
>> libvirt when running with the qemu:///session URI.
>>
>> Is there a desire to get to a point where libvirt can do everything
>> under a session URI that it can do today under a system URI? Then
>> libvirt and guests could all run unprivileged. I'm sure it's a lot
>> of work.. I'm just asking. :)
>
> Well if you want to give a VM a raw block device someone/thing needs to
> be running privileged to set an ACL on the device to le the unprivileged
> VM use it. Similarly for PCI device passthrough. Traditionally in the
> qemu:///system case, libvirt can deal with this. In a qemu:///session
> case the sysadmin would have had to setup ACLs/permissions on the
> devices / files ahead of time.
Perhaps these are things that could eventually be taken care of by a
setuid root helper with reduced capabilities, allowing libvirt to run
unprivileged.
--
Regards,
Corey Bryant
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-14 14:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1345068639-19528-1-git-send-email-mhcerri@linux.vnet.ibm.com>
2012-09-11 18:13 ` [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes Corey Bryant
2012-09-13 20:36 ` Marcelo Cerri
2012-09-14 8:40 ` Daniel P. Berrange
2012-09-14 13:31 ` Corey Bryant
2012-09-14 13:51 ` Daniel P. Berrange
2012-09-14 14:44 ` Corey Bryant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.