[apparmor] [PATCH] profiles: Grant access to systemd-resolved in the nameservice abstraction

[John Johansen]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161012/fbcfe401/attachment.pgp>