* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).