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

[Tyler Hicks]

On 2014-01-09 12:59:28, 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
> 

Thanks for explaining this so well!

> 
> but for now I would keep it as ix, sorry I didn't catch that on my first review
> 

You didn't miss anything. The patch you reviewed kept the rule as ix.
Jamie proposed to change it to Pix in a later reply.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140109/dd16ee7b/attachment.pgp>