[apparmor] "default"/"system" profile

[Steve Beattie]

On Wed, May 22, 2013 at 12:32:47AM -0700, John Johansen wrote:
> On 05/21/2013 10:57 AM, Steve Beattie wrote:
> > On Tue, May 21, 2013 at 12:49:32AM -0700, John Johansen wrote:
> >>> 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

As an aside, one of the nice features we could support by making
namespaces first class policy objects is to provide syntax for defining
flag defaults for all profiles in namespace. For example, setting
(filesystem) namespace relative or chroot relative attachment, or 'kill
on reject' as default behavior for profiles in just that namespace.

> >>>>   - 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 *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.
> > 
> well in this case unconfined would be replaceable and renameable so
> if you wanted to reconfine those processes you could and you could
> have a different name than unconfined.

Reflecting upon on it more, I think having apparmor policy revert to
a known state/name upon removal is for the best. One of the edge cases
that I was thinking about here was that if the default policy had been
subject to renaming replacement or had been adjusted to point to a
different name by policy, then on removal followed by a subsequent
policy load, if the policy relied on the known default name rather
than setting the default attribute explicitly, an administrator could
set themselves up such that the default policy on Ux transitions was
not what they intended.

Of course, this can also happen on a full policy reload with either
renaming replacement or modification of the default attribute that
occurred in the policy being replaced, if care is not taken with the
replacement policy.

> >>>>     - if the namespace is removed
> >>>>       - all profiles in the namespace, including the current default profile, are replaced by the parent namespaces default profile.
> >> 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.
> > 
> right. I was hoping at this level to leave the process tracking and killing
> to other mechanisms. But maybe we should put them into a special kill
> profile.
> 
> Having a child slip from confined sub namespace to potentially unconfined
> feels very wrong.

Well. On the one hand, if you as an administrator didn't want to have
this happen, why did you unload all policy for the namespace? That
said, the essential question is, would it be surprising behavior
from an administrator's point of view? What behavior would be least
surprising?

> However if the process is stacking across a namespace its not quite so
> bad as the new confinement is the intersection of the stacks profile from
> the parent namespace and the default of the parent namespace.
> 
> still killing does feel like the correct solution.

I can see the desirability of it.

-- 
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/20130522/e9b39764/attachment.pgp>