[apparmor] "default"/"system" profile

[Seth Arnold]

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.

> 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.

>   - 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.

> Unconfined mode transition is pix based not pux based
> - this allows tracking different task trees with separate unconfined
>   profiles that might later be replaced.

Thanks John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130520/1a51bfc5/attachment.pgp>