[libvirt] [PATCH] apparmor: support finer-grained ptrace checks

[Guido Günther]

Hi,
On Fri, Sep 22, 2017 at 11:30:39AM -0500, Jamie Strandboge wrote:
> On Fri, 2017-09-22 at 17:46 +0200, Guido Günther wrote:
> 
> ...
> 
> > What I don't understand yet is why we have in libvirt-lxc:
> > 
> > > diff --git a/examples/apparmor/libvirt-lxc b/examples/apparmor/libvirt-lxc
> > > index 4bfb503aa..0db137de0 100644
> > > --- a/examples/apparmor/libvirt-lxc
> > > +++ b/examples/apparmor/libvirt-lxc
> > > @@ -3,6 +3,9 @@
> > >    #include <abstractions/base>
> > > 
> > >    umount,
> > > +  dbus,
> > > +  signal,
> > > +  ptrace,
> > > 
> > >    # ignore DENIED message on / remount
> > >    deny mount options=(ro, remount) -> /,
> > 
> > Why does it need dbus and why can't we go with a restricted ptrace and
> > signal specifications like in the libvirt-qemu case:
> > 
> > > +  signal (receive) peer=/usr/sbin/libvirtd,
> > > +  ptrace (tracedby) peer=/usr/sbin/libvirtd,
> > 
> > maybe having to add /usr/lib/libvirt/libvirt_lxc into the mix. (I'd
> > check myself but due to the lack of ustream support I can't). Maybe just
> > an omission?
> 
> I'm not sure how the skew got there, but suspect it was simply that they were
> developed at different times, perhaps on different distributions initially where
> is might've looked consistent with the submitter's (perhaps distro-patched)
> libvirt-qemu.
> 
> All that said, in the qemu case, we know that qemu is launching a kernel and
> that accesses within the guest are mediated by whatever happens to be running in
> there and libvirt-qemu policy is for hypervisor. For libvirt-lxc, the host's
> kernel is mediating the access for the guest, so if that kernel has, for
> example, signal mediation, since the container is confined by apparmor it will
> need signal rules. Ideally we wouldn't use a bare signal rule, but instead
> something like:
> 
>   signal peer=@{profile_name},
>   signal (receive) peer=unconfined,
>   signal (receive) peer=/usr/sbin/libvirtd,
> 
> As it happens, the base abstraction in AppArmor 2.9+ has the first two rules,
> so, yes, we should be able to do as you suggest for signal and just have the
> last one.
> 
> The base abstraction has similar rules for unix, but I don't think we need a
> 'unix (receive) peer=/usr/sbin/libvirtd,' in libvirt-lxc unless there is
> something in the guest that libvirtd can connect to in some manner.
> 
> As for ptrace, it is a little different because the base abstraction in 2.9+ has
> this:
> 
>   ptrace (tracedby),
> 
> So this rule is not actually needed:
> 
>   ptrace (tracedby) peer=/usr/sbin/libvirtd,
> 
> The base abstraction has nothing to say about dbus (there are other abstractions
> that can be used, but libvirt-lxc is not using them). dbus rules are different
> than the other three because it isn't the kernel that is enforcing them, but
> dbus-daemon (dbus-daemon uses libapparmor to query the kernel to ask if an
> access of a connecting process is allowed or not by asking if the the policy
> that is loaded for the connecting process' security label (eg, profile name)
> allows it, and then dbus-daemon will do the actual allow/deny. Therefore, if
> dbus-daemon in the guest has apparmor support (and it is allowed to use sysfs
> for the host's apparmor within the container's mount namespace), then dbus-
> daemon will need some dbus rules. I don't know if libvirt-lxc exposing enough of
> sysfs for this to work all work, but if it did I *suspect* (but haven't tested
> this myself) that all that would be needed would be (the parentheses are needed
> for this rule):
> 
>   dbus peer=(label=@{profile_name}), 
> 
> since everything in the container will run under the same profile name, ie, that
> of the container. Like with 'unix', I don't think we'd need an extra rule for
> 'dbus (receive) peer=(label=/usr/sbin/libvirtd),' unless there is something in
> the guest that libvirtd can connect to in some manner.
> 
> Hope this helps!

A lot! Since I can't really test dbus and signal rules at the moment I
make sure too look at this again once they arrive in mainline kernels
(in the hopefully not too distant future).
Thanks again!
 -- Guido