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

[John Johansen]

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