[apparmor] "default"/"system" profile

[Steve Beattie]

On Tue, May 21, 2013 at 12:49:32AM -0700, John Johansen wrote:
> On 05/21/2013 12:07 AM, Steve Beattie wrote:
> >> - 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
> 
> yes and no. If a namespace is created as part of a profile load, that
> profile will be the "init" profile and the default profile until such
> time as a default profile is loaded.
> 
> This really isn't any different from kernel boot where the root namespace
> is seeded with the "initial" profile.

Sort of. The seeded initial profile for the root namespace is
synthetically generated (granted, because we have no other choice),
and the default is not replaced by whichever profile is the first
one loaded after that, but by an explicit policy choice. Whereas for
a non-root namespace, you're proposing whichever profile is loaded
first for that namespace becomes the default, which feels like an
implicit behavioral artifact of policy load order.

> Also this make it compatible with what we have today.

It's not compatible behavior, though, is it? Our existing behavior is
that when you create a new non-root namespace by loading the first
policy for that namespace, you also get the 'unconfined' profile as
the default policy for that namespace.

> > namespaces? Or are you afraid that the difference between root and
> > non-root namespace attributes will be too confusing? Do you foresee
> 
> err, I don't follow? As our namespaces have been set up each is independent
> of the other, and tasks can't leave or see the higher namespace.

Sorry, the behavioral distinction I was trying to draw between the
root namespace and non-root is that, even if we allowed some way in
policy of specifying an initial profile for namespaces, unless we
did something like compile the policy into the kernel, it would be
ignored for the root namespace, because of the realities of booting
and bootstrapping.  That's not necessarily true for things like
containers using non-root level apparmor namespaces.

> > anything besides LXC/containers that would cause an administrator to
> > specify an initial policy attrribute for a non-root namespace?
> > 
> The way I proposed things there is no initial policy attribute, just a
> default profile attribute. In the case of initial namespace setup on
> boot and setup of a child namespace that attribute points to the only
> profile until a policy load defines which profile should be the default.

Ah sorry, I had misconstrued what you were proposing, and thought there
was an initial attribute. I grant that it really is a bootstrapping
artifact more than anything.

> And yes the initial profile load when setting up a namespace could
> very well have multiple profiles, and could set the default profile
> attribute explicitly.

I would argue that, if we keep the 'first profile in becomes the
default for non-root namespaces" semantics, we should at the very
least recommend as best practice always setting the default policy
explicitly.

> > 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.
> > 
> true
> 
> > 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.
> > 
> yeah we are going to have to think about it carefully

Agreed.

> right now namespaces are strictly hierarchical and you never reference
> your namespaces name, as from a profile level policy pov you are always
> in the root namespace.

As an aside, what is the current syntax for indicating a sub-sub-level
namespace?

> >>   - 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.
> >
> sure, if its not marked on the profile that is easier
> 
> however its still an error to have multiple stanzas declaring different
> default profiles.

Absolutely.

> >>   - 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?
> > 
> yep its a problem, I don't have a clean solution for it atm
> 
> > I could also see as another option it reverting to whatever the
> > initial policy is, though I'm less than enthusiastic about it.
> > 
> no, the initial policy it self may have been replaced/removed

For replaced, I was thinking "you asked to replace it, you get what
you get". For removed, well, we'd still need a fallback, just as if you
remove all policy.

I *almost* kind of like the 'set the current default profile to
unconfined' and carry on, for simplicity of behavior sake. I need to
think more about the implications for reloading policy after such an
event, however.

> 
> >>     - 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.)
> > 
> It has its profile replaced to the parent namespace's unconfined profile.

Okay.

> The other option is to kill all tasks within the namespace that is being
> removed, but we can't do this directly (well not easily). So it would
> likely be achieved through some special profile replacement.

Hopefully, namespace removal that doesn't involve the teardown of
all processes that have that apparmor namespace applied is an edge
case. The common cases that I see for namespace removal would be
things like 'the related container is shutting down', where all
processes should be ending anyway.

-- 
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/489c9abb/attachment.pgp>