On Thu, 2010-09-23 at 18:03 +0100, Daniel P. Berrange wrote:
> On Thu, Sep 23, 2010 at 11:49:21AM -0500, Jamie Strandboge wrote:
> > On Thu, 2010-09-23 at 16:10 +0100, Daniel P. Berrange wrote:
> > > On Mon, Aug 16, 2010 at 02:45:02PM -0500, Jamie Strandboge wrote:
> > > > Author: Jamie Strandboge <ja...@canonical.com>
> > > > Description: AppArmor example profile adjustments:
> > > >  - libvirt-qemu: allow guests setgid and setuid so qemu can drop 
> > > > privileges
> > > >  - virt-aa-helper:
> > > >    + allow access to @{PROC}/[0-9]*/net/psched
> > > >    + allow searching /sys/bus/usb/devices/
> > > >    + deny access to /dev to suppress confusing, non-fatal profile 
> > > > denials
> > > >    + allow access to user-tmp abstraction
> > > > Bug-Ubuntu: LP: #579584, LP: #565691
> > > > 
> > > > diff -Naurp libvirt.orig/examples/apparmor/libvirt-qemu 
> > > > libvirt/examples/apparmor/libvirt-qemu
> > > > --- libvirt.orig/examples/apparmor/libvirt-qemu 2010-04-06 
> > > > 16:14:52.000000000 -0500
> > > > +++ libvirt/examples/apparmor/libvirt-qemu      2010-08-13 
> > > > 16:46:34.000000000 -0500
> > > > @@ -1,4 +1,4 @@
> > > > -# Last Modified: Mon Apr  5 15:11:27 2010
> > > > +# Last Modified: Fri Aug 13 16:38:32 2010
> > > >  
> > > >    #include <abstractions/base>
> > > >    #include <abstractions/consoles>
> > > > @@ -9,6 +9,10 @@
> > > >    capability dac_read_search,
> > > >    capability chown,
> > > >  
> > > > +  # needed to drop privileges
> > > > +  capability setgid,
> > > > +  capability setuid,
> > > > +
> > > >    network inet stream,
> > > >    network inet6 stream,
> > > 
> > > Does QEMU really need this ? The libvirt QEMU driver will drop
> > > privileges from root:root to qemu:qemu after forking, but before
> > > the /usr/bin/qemu binary is actually exec'd. 
> > 
> > Yes. Users were seeing errors like:
> > libvir: QEMU error : cannot change to '109' group: Operation not
> > permitted
> > libvir: QEMU error : cannot change to '104' user: Operation not
> > permitted
> 
> Hmm, that's a libvirt error rather than a QEMU error. Is the restricted
> AppArmour policy taking effect *before* the actual QEMU binary is exec()d ?

This is related to the stacked security driver implementation.
Specifically, if I strace libvirtd, I see in one of its threads:
gettid()                                = 20306
open("/proc/20306/attr/current", O_WRONLY) = 3
write(3, "changeprofile libvirt-7d781722-6"..., 58) = 58
close(3)                                = 0
chown("/tmp/qrt-test-libvirt/libvirt/qatest/qatest.img", 116, 123) = 0
setregid(123, 123)                      = -1 EPERM (Operation not
permitted)

This chown appears to come from qemuSecurityDACSetProcessLabel(). What
seems to be happening is that in __virExec() we call the security hook
and the apparmor hook is being called before the DAC one, so we
aa_change_profile() to the more restricted libvirt-<uuid> profile. It
seems that it would be preferable to reverse the calling order of the
hooks, but I am not sure how to do that.

-- 
Jamie Strandboge             | http://www.canonical.com

Attachment: signature.asc
Description: This is a digitally signed message part

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to