Hi, On Fri, Sep 22, 2017 at 10:29:22AM -0500, Jamie Strandboge wrote: > On Fri, 2017-09-22 at 14:52 +0200, Guido Günther wrote: > > > + ptrace, > > > > ^^^^^^^ > > > > This single line is enough to make things work for me on 4.13. AFAIK > > dbus mediation is not upstream yet and I think unix socket and signal > > support is neither. Should we drop these for now (the syntax and > > behaviour might change while things are being upsreamed)? > > Note that if you are upstreaming profile changes for ptrace, you may as well add > them for signal and dbus because an apparmor parser that can understand 'ptrace' > can understand the other two. The parser is designed to deal with kernels that > don't have the full set of apparmor capabilities. The policy syntax for all of > these rules should not change as part of upstreaming dbus and unix. > > 'unix' is probably ok to add because support for it was added to the parser in > devel releases of AppArmor within 6 months of ptrace and signal. 'dbus', > 'ptrace', 'signal' and 'unix' were officially introduced in 2.9[1]. By adding > 'ptrace' you are saying AppArmor 2.9 is required, therefore, the other 3 are > parseable. The assumption then is that upstreaming the kernel side will never affect the parser, that's fine. Thanks for the clarification! That makes the libvirt-qemu and usr.sbin.libvirtd parts look good. 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? Cheers, -- Guido -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
