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
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
