[apparmor] [PATCH 2/4] profiles: Add strict session bus abstraction

[John Johansen]

On 01/09/2014 12:59 PM, John Johansen wrote:
> On 01/09/2014 12:28 PM, Tyler Hicks wrote:
>> On 2014-01-07 16:39:44, Jamie Strandboge wrote:
>>> On 01/03/2014 04:26 PM, Tyler Hicks wrote:
>>>> Move the file rule from the existing permissive session bus abstraction
>>>> into a new strict session bus abstraction.
>>>>
>>> Thanks for all these! This is a really good idea. Sorry for not responding sooner.
>>
>> No problem! I thought you'd like these patches since they should make
>> some of your profiles smaller. :)
>>
>>> ...
>>>>
>>>> diff --git a/profiles/apparmor.d/abstractions/dbus-session b/profiles/apparmor.d/abstractions/dbus-session
>>>> index 76a7bbf..2eda4e0 100644
>>>> --- a/profiles/apparmor.d/abstractions/dbus-session
>>>> +++ b/profiles/apparmor.d/abstractions/dbus-session
>>>
>>> ...
>>>
>>>> -  /usr/bin/dbus-launch ix,
>>>
>>> ...
>>>
>>>> diff --git a/profiles/apparmor.d/abstractions/dbus-session-strict b/profiles/apparmor.d/abstractions/dbus-session-strict
>>>
>>>> +  /usr/bin/dbus-launch ix,
>>>
>>> ...
>>>
>>> First off, can we change this to be 'Pix'?
>>
>> IMO, modifying this rule should happen separate from this patch set. (but that
>> doesn't mean we can't discuss it...)
>>
>>
>> It used to be Pix. Take a look at r1722. Here's the commit message:
>>
>>   profiles/apparmor.d/abstractions/dbus-session: Per discussion with John
>>   Johansen, use 'ix' instead of 'Pix' for dbus-launch since if someone happens to
>>   define a profile for dbus-launch and it is loosely confined, then users of this
>>   abstraction could end up launching a program via dbus-launch in a less confined
>>   manner than intended. This sort of thing should not be possible via an
>>   abstraction (and people are always free to profile using Pix if they prefer).
>>
>> Would 'Pix -> dbus_launch', as you suggest below, fix the problem that John
>> pointed out? I think it would but I'm not 100% sure.
>>
> No, this just locks down what profile will be used to a profile with a specific
> name.
> 
>   Eg. using ix
>     task a confined by A calls dbus-launch b
>     dbus-launch is confined by A
>     b (if it is allowed) has its confinement determined by A
> 
>   Eg. using Pix, same as ix if no profile defined otherwise, for a profile D defined
>   for dbus-launch
>     task a confined by A calls dbus-launch b
>     dbus-launch is confined by D
>     b (if allowed by D) has its confinement determined by D
> 
> The difference between using a plain Pix as above and Pix -> dbus-launch is that
> the profile is specified to always be the dbus-launch profile. Where the bare Pix
> will choose the "best" profile.
> 
> It could be dbus-launch, if it has an attachment specification
>   profile dbus-launch /usr/bin/dbus-launch { }
> 
> however you generally wouldn't want to do that as it would apply to every invocation
> of dbus-launch and would have to be very loose
> 
> It could be a generic profile
>   profile generic /usr/bin/* { }
> 
> etc.
> 
> specifying the dbus-launch profile with Pix -> dbus-launch, allows for a generic
> dbus-launch profile that doesn't attach from unconfined, so it can be tighter
> than a dbus-launch profile with the generic attachment. However this is still not
> what you usually want to do for a confined application. Generally you want it
> to use the transitions defined by A.
> 
> What this really is asking for is a form of profile composition. Where the base
> permissions for dbus launch are contain in a separate profile so they don't
> pollute the current profile, and the transitions for the current profile are
> used. Interestingly enough stacking can give this to us.
> 
>   Px -> &//dbus-launch,
> 
> the dbus-launch profile will need a transition defined in it so that it get
> dropped when it launches b
> 
> that is
> dbus-launch {
>   /** ux,
> }
> 
> this will cause the dbus-launch profile to be dropped from the stack, allowing
> b's transition to be entirely defined by profile A
> 
> 
> but for now I would keep it as ix, sorry I didn't catch that on my first review
> 
> 
Sigh no ignore not stacking, the stack is a pure intersection. This is the
composition work which is even further down the road

that should be
  Px -> +//dbus-launch

obviously I need to go back to bed