[apparmor] "default"/"system" profile

[John Johansen]

On 05/20/2013 02:16 PM, Seth Arnold wrote:
> On Sun, May 19, 2013 at 05:07:16AM -0700, John Johansen wrote:
>> When a profile is created the first profile it is created with is the
>> "init" profile.
>> - this profile is replaceable, and set as the default profile
>> - For the root namespace (namespace setup on boot)
>>   - this profile is setup in the unconfined mode
>>   - the name of this profile can be set by a kernel parameter
>>       apparmor.init=<name>
>>     or maybe
>>       apparmor.init_profile=<name>
> 
> I prefer init_profile but won't object to init.
> 
>>   - the default name for the "init" profile could be any of (vote for
>>     your favorite)
>>     - init
>>     - initial
>>     - unconfined
>>     - something else???
> 
> Ooh. 'initial' is tempting. I know I used 'init' in the past for this,
> but didn't like the connotation that suggests that we might be
> special-casing init in the kernel. 'initial' would seem to answer that
> concern while still being easy to tie to init.
> 
>> - For all other namespaces
>>   - the first profile is the "init" profile, and it is set as the
>>     default profile
>>     - its name is set by the profile load that caused the creation of the namespace
>>       - namespaces are created by loading a profile to a child
>>         namespace that doesn't exist
>>       - the parent namespace can preseed policy in the child namespace
>>       - this allows lxc to setup a namespace that imitates real boot
>>     - its mode is set by the profile load
> 
> I don't love the dichotomy between "the first namespace" and "all other
> namespaces", but I have a feeling it'll look natural when used.
> 
We its really just a matter of who is setting up the namespace. Early
kernel boot or the process that is setting up the container virtual machine
unfortunately they have to be a little different, but they should look the
same once set up.


>> The default profile can be any profile in the system. That is just a
>> regular profile that has been selected as the default profile
>>   - the "init" profile is the first default profile for a namespace
>>   - there is no set name for the default profile. That is the default
>>     profile is an attribute of the namespace
>>   - the default profile is set/changed by loading a profile that is
>>     marked as default
>>     - the marking is done as a profile flag
>>         profile foo (default) { }
>>       yes this can be combined with other profile flags
>>         profile foo (default, unconfined) { }
>>     - this allows the setting of what is default to be indicated within policy
>>     - the most recently loaded profile that is marked as default
>>     - loading of a profile that is marked as default and that is NOT a
>>     replacement for the current default does not do profile
>>     replacement on the current default eg. if "init" is the current
>>     default, and a new profile named "foo" is loaded and marked as the
>>     default profile, the tasks "confined" by init will remain confined
>>     by init, but the default profile will be switched to "foo" so that
>>     subsequent transitions to the default profile will transition to
>>     foo
>>   - transitions
>>     - u/Ux become a transition to the default profile
>>     - u/Ux becomes deprecated
>>       - we could replace it with d/Dx or something else as part of the
>>         policy language
> 
> The amount of churn to sed Ux into Dx would be unfortunate. And yet 'u'
> definitely gives the wrong impression for what the end result would be,
> some of the time. I feel like this point needs further discussion, or
> further alternatives, or something.
>
sure suggest away

 
>>   - replacement
>>     - if the default profile is replaced, its replacement becomes the
>>       default
>>     - unless another profile within the replacement set specifies it
>>       is the default
>>     - it is an error for an atomic replacement set to have to profiles
>>       marked as being the default profile
>>   - removal
>>     - removal of profile within the namespace causes a replacement to
>>       the namespaces default profile
>>     - if the default profile is removed, we could do any of the following
>>       - disallow the removal (unless the namespace is being removed)
>>       - set the default profile to unconfined mode, without actually
>>         removing it
>>       - replace with a profile named "unconfined" that is replaceable,
>>         and becomes the new default profile
> 
> I prefer this, creating a new "unconfined" or "default" on the fly.
> 
>>     - if the namespace is removed
>>       - all profiles in the namespace, including the current default
>>         profile, are replaced by the parent namespaces default profile.
>>   - the default profile will be exposed to userspace via a file under
>>     its namespace in aafs
>>     - we could allow this file to be written to allow manually
>>       switching the default profile
> 
> Is there anything wrong with just trying for specified only in policy
> for a little while first? It doesn't seem like it'd be hard to write nor
> hard to use, but I'm not quickly seeing the problem it solves and the
> complexity of profiles not matching the kernel's view is potential for
> misunderstanding.
> 
no that was my plan, start with in policy only + file to introspect, but
not change, and we can extend it later if need be.