On 05/15/2013 05:13 PM, John Johansen wrote:
> So this is a new attempt to frame the default/init/system profile discussion
>
Alright, here is a new proposal on it.
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???
- 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
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
- 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
- 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
Unconfined mode transition is pix based not pux based
- this allows tracking different task trees with separate unconfined profiles
that might later be replaced.
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
