On 10/12/2016 06:08 AM, John Johansen wrote: > On 10/12/2016 01:17 AM, Steve Beattie wrote: >> 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 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. >>>> >>>>  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. >> > Ah got it. Thanks >
So this has interesting implications for future policy compiles where we have been planning to have the compiler compile in all compiler supported rules so that the same policy can be used on different kernels. Where this case is calling for some cross feature interaction, and I would assume we would like that USE_RESOLVD bool to be by default automatically set based on whether the kernel supports dbus policy. Which would also mean the parser exporting the supported feature set to policy, which is something I have been meaning to do any ways as part of the policy versioning work. I think we can still proceed with the plan to support broader kernel feature sets with a single compile if we keep track of which feature conditionals are used in policy. Doing so would mean the blob generated would get invalidated when that feature conditional was changed at least until kernel vars land, at which point we could resolve the conditional in kernel. Does that sound like a reasonable approach?
Description: OpenPGP digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor