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

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.

Attachment: signature.asc
Description: OpenPGP digital signature

AppArmor mailing list
Modify settings or unsubscribe at: 

Reply via email to