[apparmor] replacing unconfined and doing global policy

[John Johansen]

On 04/06/2012 08:08 AM, Christian Boltz wrote:

>>
>> 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")
> 

Either works for me I can understand the desire to leverage the existing
syntax

>>>>    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...
> 
yeah I was positive you did but went into a long description anyway,
and then missed out add the last little bit

the reason we allow switching to unconfined is two fold.
1. To not restrict what policy authors can do (much like giving access to
   ux.
2. So that it can be specified when changing into a new namespace
  eg.
    /foo/bar px -> :ns2:unconfined,

  change_profile -> :ns2:unconfined,

  Often when changing namespace the correct solution is the unconfined
  or (default profile)

>> 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.)
> 
Hrmmm sort of, it certainly could manifest it self as a symlink but at
least in implementation it would need to track the tasks using it separate
from those using unconfined.

As to whether its in the list, that depends a little on the behavior, does
a task that is assigned the default profile, show up as default.  Or
does it show as the profile it is referencing.  So if default is set to
unconfined then tasks assigned to default get listed as being unconfined.
When default gets replaced they now show up as belong to the new default.

Basically we are proposing splitting the notion of default from unconfined
and we need to nail down exactly what we want.

Do we want to add new transition types
  dx
  pdx

or some such, when people used ux, pux did they really mean unconfined or
should it be the default, etc.