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



Attachment: signature.asc
Description: OpenPGP digital signature

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to