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

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

Attachment: signature.asc
Description: PGP signature

AppArmor mailing list
Modify settings or unsubscribe at: 

Reply via email to