[apparmor] "default"/"system" profile

John Johansen john.johansen at canonical.com
Thu May 16 21:30:49 UTC 2013


On 05/16/2013 03:33 AM, John Johansen wrote:

<< snip >>

>> I think the problem with all the above is that you're still conflating
>> the initial_policy that is applied to init with the default_policy, an
> 
> Sigh, no sorry I guess I wasn't clear enough. I really tried to make that
> split and provide several options for doing so while pointing out the
> issues involved. What I did do was mix the discussion of the split and
> implementation, because implementation issues have a very real impact
> on what is chosen.
> 
> The first part of the confined init discussion with parts 1-6 where
> purposely just about dealing with init. The second part default profile
> with parts a-e where about dealing with the default profile
> 
> So for example if we chose to implement things via 1. Then there does
> not need to be a "split". The policy provided in early boot determines
> whether init gets its own profile or the "default" profile. If init is
> given the default profile then it will be replaced just like every
> other task in the default profile when profile replacement happens.
> 
> c and d) However are very much in the vein of what you propose where
> init and default are separate.
> 
> I think the difference is an implementation pov mixed in. That is there
> are two profiles at the start (not one). They both exist in an unconfined
> state and can be replaced separately.
> 
> The difference between c and d is when the switch from using the init
> profile to the default profile occurs. Conceptually you can think of
> them as the same profile except for the tracking of tasks, for replacement
> it is very important to know which tasks are under which profile.
> 
> In c the split happens when a new default profile is loaded. In d the
> split happens as soon as any policy loaded.
> 
>> attribute of the 'default' or 'system' namespace. (I grant that I too
>> didn't fully see the distinction, and didn't consider it an attribute
>> of the namespace, until halfway through responding to this email.)
>>
> err I am not sure I follow, but I assume that you mean that init and
> default profiles are per namespace, which is sort of true. The default
> profile must exist per namespace. The init would depend on what we
> choose, it is fully possible to load profiles into a namespace on
> setup so that namespaces other than the root do not have to setup
> and init profile, unless they want one (like with a container acting
> as a VM)
> 
>> So let me try to unconflate them even further:
>>
>>  - When we initially boot, we have one profile in the system namespace
>>    (there are no other namespaces at this time), let's name it
>>    'initial_policy'.
>>
> yep but uh how about root namespace (system works too I am just
> emphasizing the hierarchical nature). And we have to make sure we
> can setup a subnamespace such that it looks and behaves like the
> root namespace (which they do once you transition into them).
> 
>>  - This 'initial_policy' starts out in unconfined mode. It can be
>>    replaced.
>>
> yep
> 
>>  - The default_policy attribute of the system namespace *points to*
>>    the profile 'initial_policy'. *Initially*. But we could allow
> yep
> 
>>    an administrator to change this attribute after boot to point to
>>    something besides 'initial_policy', like an administrator defined
>>    profile named 'my_nifty_default_policy'. This is a different action
>>    than replacing 'initial_policy'.
>>
> I would in fact rather avoid this as its introducing another knob for
> policy control that can be done with replacement as long as the "default"
> profile has a well known name.
> 
> Is all that the administrator has to do is replace that profile. If the
> administrator wants a different name he can define it as a boot arg
> or use renaming replace.
> 
> Renaming replace does replacement and rename at the same time, and avoids
> some of the race problems of set profile.
> 
> The issue with the default and init profiles having different names could
> be solved by having the default profile be an alias to the init profile
> until it is replaced
> 
> this is slightly different than you propose, with the difference being
> whether we introduce a new knob
> 

So just a little addendum to this, to make the implementation choices
clear. Assuming "init" and "default" are or can be split then

- the init profile is part of the namespace if it exists. The question is
  only whether a separate one exists from profile creation. This will be
  determined by the implementation choice.

- There are 3 ways to manage the split descibed in c and d.

  - a namespace attribute (what steve proposed) that is starts out
    pointing to the init profile but can be updated to point to another
    profile

    - this has the property that you could lookup what the current
      default profile is
    - can not be set by a boot parameter
    - this could be set with extension to the policy language or
      through the new aafs or both

  - a specific profile. Its created at namespace creation time and
    is aliased to the init profile. That is when used init will take
    its place, and it only becomes different after an actual profile
    is loaded with its name.

    - this could be augmented with a file in the aafs namespace to
      indicate what the current default profile is
    - can be set to different profiles with a boot parameter
    - this is implemented via standard profile replacement

  - a new profile flag that is used to indicate which profile should
    be the default, with the default switching when a profile marked
    as such is loaded.

    very similar to the specific profile but removes the need for
    a well known name.

    - could have an aafs namespace file for introspection
    - can not be set by a boot parameter
    - implemented via replacement


Note: what ever method is used we must special case the unload of the
default profile so that it always has/points to a valid profile

I don't really care which we use, they each have their advantages and
disadvantages. Basically I withdraw my previous objection

> I would in fact rather avoid this as its introducing another knob for
> policy control that can be done with replacement as long as the "default"
> profile has a well known name.


>>    Note that changing the default_policy namespace attribute would not
>>    change the existing attachment on init and it's children, which have
>>    'initial_policy' still applied, only future U/ux transitions would
> right
> 
>>    be affected (though that's one of the reasons why it's important
>>    to define whether unconfined mode implies '/** pix' or '/** pux').
> yes
> 
>>    Of course, 'initial_policy' can be reloaded/modified as well,
>>    such that it has '/bin/init ix, /** pux' so that re-execing itself
>>    will keep 'initial_policy' applied but 'my_nifty_default_policy'
>>    will get applied to anything else it execs. All this could occur
>>    before or after your initrd completes.
>>
> yes
> 
>> Does that help at all?
>>
> sure it cleared up how you are seeing it
> 
>> Now I grant that we don't really have anything toolwise that works
>> on a namespace independently; because they were grafted on, they've
>> always been tightly coupled to the policies that make them up.
>>
> yes they are, though there has always been plans to add additional
> controls to them
> 
>> (My only hesitation is the issue cboltz raised, that if you configure
>> your default_policy too restrictively, you may not be able to complete
>> booting, and you wouldn't have a kernel command line argument to
>> tweak to not change the default_policy to 'my_nifty_default_policy'.)
>>
> sure you can at least if its a separate profile name that aliases init
> at first. you can also boot with apparmor=0 if you really need
> 
>>> Choosing a name
>>>
>>>   IFF we choose to split the init and default profile then I think the
>>>   names should be
>>>    init and default (or maybe system)
>>>
>>>   otherwise
>>>     system seems to make sense
>>
>> I think getting the concepts nailed down first is more important than
>> the specifics of the names.
>>
> yep
> 
>  
> 
> 




More information about the AppArmor mailing list