[apparmor] [PATCH 4/5] And the ability to specify the name andattachment of the profile separately. It does not allow for the attachmentspecification to begin with a variable however since variables in profilenames is not currently support this should

[John Johansen]

On 11/30/2010 01:21 AM, Seth Arnold wrote:
> Something I've never understood about the namespaces is how they would be used.
> 
Well for anything that would want its own profile space, child profile are in effect a special version
of a namespace except that they still have access to the parent.

> Would they be used for openvz or vservers instances? 
that is the plan, this would allow for a container to have its own profile set

> Explicit names in profiles would seem counter-productive at first, you wouldn't want processes in the WebServer namespace to load policies in the DataBase namespace just by using a keyword...
> 
Ah but they wouldn't, because namespaces are hierarchical, they can't see their parent or siblings,
only them self as root and any child namespaces they may contain.

Now whether having the namespace name be specified with in the policy is a good idea is different
question all together.  Generally I see namespaces being setup and loaded using the --namespace
option of the parser, or via change_profile into a new namespace and then letting the namespace load
its own policies.

> Would they be used for user profiles?
yes that is the plan as well.  Basically the user will get their own namespace to load their own
profiles in.  And profile stacking will be used to allow the system and user profiles to coexist.

> Again, I don't see how explicit names in the profiles would help; whichever euid loads the profiles seems a better choice.
> 
Explicit names are a completely separate issue from using euids to identify who loaded profiles.

The explicit naming of profile of this patch allows for providing sensible profile names, instead
of the attachment specification.  eg. a profile name of firefox instead of /usr/lib/firefox-3.6.12/firefox-*bin

The more regexs that get added to the profile name the more it will be needed.  It also allows
for the logical naming of profiles eg.

profile default /** { }


Now to naming of namespaces, that just allows them to be identified and looked up.  Its really
not much different than directories for a filesystem.

As for using euid for profile loads, what if multiple users have CAP_MAC admin, where should their
policy go?  Handling the loading of user policy is actually one of the little details that needs
to be worked out.

> Or is it for libvert, and the profiles aren't really supposed to be mutable from inside the guests?
> 
well that is another possibility as well, and no profiles shouldn't be mutable from within a guest.