On Tue, Oct 11, 2016 at 11:58:06PM -0700, John Johansen wrote: > On 10/11/2016 11:03 PM, Steve Beattie wrote: > > I don't like this for precisely the reason above. Access to the D-Bus > > system bus would be allowed (modulo DAC and D-Bus policy) even on > > systems that do not use systemd-resolvd, and thus have no reason to > > access to the system D-bus at all. > > > > I think this either needs to stay as an Ubuntu patch or should be > > present but commented out[0] until the necessary apparmor bits that D-Bus > > needs have made it into the upstream kernel. That said, I welcome input > > specifically from non-Ubuntu downstreams here on this, > > > > Thanks. > > > > [0] or the support for conditional variables present in the apparmor > > policy language dusted off and made use of. > > > > > Conditionals aren't needed, just a version of the apparmor userspace that > supports the dbus syntax. In fact as conditionals are currently implemented > they won't work without understaning the syntax anyways, so these rules > will break older versions of apparmor regardless. > > With the dbus syntax support, the policy will compile even if the dbus > extension is not there to enforce it. So unless someone is setting compiler > flags to fail on warnings, the dbus rules are already conditional on > support.
While it is true that the parser will drop dbus rules if the kernel doesn't support them, it will not also drop the granted access to the dbus system bus socket, which is the troubling part. The dbus kernel rule support is not what the conditional I envisions is about, it's more of a USE_RESOLVD boolean. We have four states: (1) kernel supports dbus rules resolvd used (2) kernel supports dbus rules resolvd not used (3) no kernel dbus rule support resolvd used (4) no kernel dbus rule support resolvd not used Case 1 is what we have in Ubuntu 16.10, and the rules we've added to nameservice abstraction make sense for it. Case 2 is for example Ubuntu 16.04. There, adding the rules unilaterally to the nameservice abstraction makes the policy a bit loose, but modulo bugs in the dbus mediation, is not too large an increase. Case 3 is unpleasant, in that networked applications will want access to the system dbus, and we can't enforce anything tighter than that. Case 4 though, we've just allowed networked applications unrestricted access to the system dbus that they do not need. Enclosing the additions to the nameservice abstraction in a USE_RESOLVD conditional would improve the situation in case 4 the most, as well as case 2. -- Steve Beattie <sbeat...@ubuntu.com> http://NxNW.org/~steve/
signature.asc
Description: PGP signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
