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.
>
> Secondly, I wonder if this rule should be in the permissive session bus
> abstraction rather than the strict one. I have quite a few profiles that use
> dbus rules without the existing dbus abstractions, and only one has a
> /usr/bin/dbus-launch rule. Moving '/usr/bin/dbus-launch Pix,' out of
> dbus-session-strict seems to make a lot of sense and I suggest we just do
> that.
> What do others think?
I think that's a good idea. I'll reply with a v2 of this patch.
>
> Lastly, what I have for that profile is:
I suppose we should hash out what the r1722 commit message means for using Pix
before hashing out the dbus-launch profile.
Tyler
>
> /usr/bin/dbus-launch Cx -> dbus_launch,
> profile dbus_launch {
> #include <abstractions/base>
> #include <abstractions/nameservice>
> #include <abstractions/X>
> /usr/bin/dbus-launch r,
> }
>
> This confinement for dbus-launch is mildly interesting, but I think we might
> have some issues if we use a child profile in this exact manner in the
> abstraction. We could ship the profile outside of the abstraction though, and
> use 'Pix -> dbus_launch' in the abstraction instead. It doesn't give much
> added
> security, but dbus-launch clearly doesn't need much access.
>
> --
> Jamie Strandboge http://www.ubuntu.com/
>
> --
> AppArmor mailing list
> [email protected]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/apparmor
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
