On 10/12/2016 06:24 AM, John Johansen wrote: > 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[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. >>> >> 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? >
BTW by automatically populated I meant doing something like $USE_RESOLVD=$KERNEL_FEATURE_DBUS or some such so that $USE_RESOLVD acts as documentation of what the intent is and so that an admin can manually over ride it.
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
