[apparmor] "default"/"system" profile

Tue May 21 07:07:36 UTC 2013

On Sun, May 19, 2013 at 05:07:16AM -0700, John Johansen wrote:
> Alright, here is a new proposal on it.

I'm generally on board. A couple of comments/questions inline:

> 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>
>   - the default name for the "init" profile could be any of (vote for your favorite)
>     - init
>     - initial
>     - unconfined
>     - something else???

I'm terrible at picking meaningful yet not unwieldy names, so no
strong opinion from me on either name. I liked Seth's argument for
'initial', but really, as long as it's not called "throatwarbler
mangrove" by default, I'll probably be okay with it. :)

> - For all other namespaces
>   - the first profile is the "init" profile, and it is set as the default profile

The first profile loaded? So profile load order matters here? Is there
a reason not to make this explicit in policy somehow, for non-root
namespaces? Or are you afraid that the difference between root and
non-root namespace attributes will be too confusing? Do you foresee
anything besides LXC/containers that would cause an administrator to
specify an initial policy attrribute for a non-root namespace?

(I note that we generally have been on a path to make things explicit
via policy rather than rely on implicit behaviors, a direction I am
in favor of.)

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

You mean whether it's in unconfined mode or not? Or something
more/else?

> 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

When the notion that the default profile should be considered
an attribute of the namespace started becoming apparent to me, I
initially considered expressing it in policy as a mode/flag on the
profile. I decided I didn't like that (and didn't propose it) because
none of our other profile flags operate in the same fashion, either
requiring the flag to be unique across the policies in the namespace,
or specific load ordering if multiple default flags are given.

It comes back to my desire to grow namespaces as first class objects
in policy (I have no doubt they are first class in implementation).
Random hand-wavy approximation of a language extension proposal:

  namespace NAMESPACE_NAME {
    attribute default = my_nifty_default_profile,
  }

but that's with 15 seconds of what passes for thought on my behalf,
with marginal consideration for consistency, etc.

Whether you could then define profiles within the namespace grouping...
well, I dunno.

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

Yes.

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

I'd like for our policy language to discourage the latter two points
from being a problem.

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

I don't care for disallowing the removal.

>       - 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... don't have a strong opinion here, except that I prefer Seth's
proposal to use 'default' over 'unconfined'. It does raise the issue
if we're magically creating profiles, what if a profile by that name
(e.g. "unconfined") already exists in the namespace?

I could also see as another option it reverting to whatever the
initial policy is, though I'm less than enthusiastic about it.

>     - if the namespace is removed
>       - all profiles in the namespace, including the current default profile, are replaced by the parent namespaces default profile.

What is our current behavior for processes in an existing non-root
namespace/profile pair, if the entire namespace is removed? (I guess
if I *really* wanted to know, I'd write a testcase or two.)

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

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

Agreed.

Thanks, John, for driving and persevering through all this.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130521/4caf5a95/attachment.pgp>