[apparmor] replacing unconfined and doing global policy

[Christian Boltz]

Hello,

Am Donnerstag, 5. April 2012 schrieb John Johansen:
> On 04/05/2012 03:31 PM, Christian Boltz wrote:
> > Am Mittwoch, 4. April 2012 schrieb John Johansen:
> >> A bit of history, and where we are at now
> > 
> > Thanks for the history lesson!
> > Can you please store your text (or a link to it) in the wiki? It
> > would be a pity if it's hidden in the mailinglist archive.
> 
> heh well most of it is actually in the spotty release notes but we
> probably should store some more notes in general with some flow to
> it, especially with the gradual but not so obvious work towards other
> features like implicit labeling.

Sounds like you just volunteered ;-)

> >> So what decisions are left to be made?
> >> - should the unconfined profile show up in profile listings?
> > 
> > I tend to say no.
> 
> What of the default profile?

The default profile will be a real profile with (optionally) some 
restrictions - therefore I'd say it should show up in profile listings.

> I was thinking of just "default" and it is initially set to unconfined

Sounds good.

> > If you want the new default_profile, use px -> default_profile.
> > 
> >>    same questions for
> >>    
> >>    /foo px -> unconfined,
> > 
> > I'd make that a parser error - something like "invalid/reserved
> > profile name". If you want unconfined, use ux. Period.
> 
> hrmmm it is a valid profile change and there have been half formed
> plan to maybe extend the named transition syntax to a list at some
> point
> 
> eg.
> 
>    /** px -> one two three inherit,
> 
> or some such which would be try "one" first if it doesn't exist try
> "two" then "three" if none of those fallback to inheriting

Interesting idea, but I'd write it as
    /** pix -> one two three,
(note the "pix" instead of "px")

> >>    and for change_profile ->unconfined,
> > 
> > Argh, this one is trickier ;-) because we have no existing rule
> > syntax to do that.
> > 
> > Does it really make sense to allow a program to leave its profile?
> > I don't really like this idea...
> 
> Actually we do, :) (sorry if you missed it, its not been well used but
> has existed since 2.3 I think)
> 
>   change_profile <executable> '->' <profile>,

I know change_profile, and apparmor.vim is my witness ;-)

My question was about the "-> unconfined" part - do we really want to 
allow a program to leave its profile and make it unconfined? I'd vote 
against it...

> So lets alter the proposal a bit.  Every namespace gets a new default
> profile alias that starts out pointing to unconfined but can be
> replaced to point to a new profile, and have all tasks using it
> switch to the new profile as well.

Sounds good.

> I think default should not show up in the profile list but when
> introspecting the namespace should have it own entry that specifies
> what profile is the default.

That sounds like you are thinking to make the "default" profile like a 
symlink.

I'd make it a normal profile and handle it the normal way. (This 
includes showing it in the profile list.)


Regards,

Christian Boltz
-- 
<cboltz> when will you release it?
<jjohansen> [...] if you want I will work on getting it up tonight
<cboltz> yes, please do it before I find another bug ;-)
<jjohansen> hehe, extra incentive to get it up quick :)
[from #apparmor]