[apparmor] unconfined mode and 'file' keyword

[John Johansen]

On 05/17/2013 01:55 PM, Steve Beattie wrote:
> [Pruning discussion scope a bit...]
> 
> On Thu, May 16, 2013 at 03:33:52AM -0700, John Johansen wrote:
>> On 05/16/2013 02:20 AM, Steve Beattie wrote:
>>> (It also raises the question for me what the bare 'file' keyword is
>>> equivalent to; looking at our apparmor.d(5) man page, I don't see that
>>> made explicit anywhere. It's a little confusing because it's intuitive
>>> what all 'network', 'dbus', or 'capability' access might mean, but
>>> because file access conflates both read/write/exec operations and
>>> policy transitions, it's not straightforward what 'file' means.)
>>>
>> ah so glad you asked, as I was going to propose making the bare file
>> keyword not imply any x permissions. Currently it does ix but I believe
>> this is wrong, and the x permissions should be separated out unless
>> they are explicitly provided.
>>
>> So bare file would imply all file permissions excluding the profile
>> (domain) permissions.
> 
> I've not given it a whole lot of thought, but that's probably a
> reasonable compromise. So the equivalent would be:
> 
>   /** rwmk,
>   link /** -> link,
> 
> (Hrm, our apparmor.d(5) manpage doesn't mention the link keyword.)
> 
>>>>   7. the unconfined profile is exposed on interfaces (historical artifact) as
>>>>        unconfined
>>>>      instead of
>>>>        unconfined (<mode>)
>>>
>>> Well, sort of. An enforcing policy was implicitly considered to be
>>> enforcing if no mode was listed in an exposed interface (which is still
>>> the case). The unconfined policy could be considered to be enforcing
>> err is it? The mode is always exposed via the current interface. The intention
>> may have been that mode was enforcing when not specified but that still
>> doesn't really change anything.
> 
> Mea culpa, was thrown off by ps -Z output. Yes, fixing that would be
> great.
> 
>>> (It's a bit unfortunate that our exec modifier U/u is shorthand for
>>> unconfined, and thus continues the conflation.)
>>>
>> yes, I'd like to deprecate its use. But we still have to define how it should
>> behave with a new default policy scheme
> 
> We could conceivably use D/dx to mean transition to the namespace's
> default_policy, and deprecate U/ux while having it as D/dx. I don't
> have a strong feeling about it, however.
>

yeah, I don't have a strong feeling there either


>>> And again, using a different name makes the distinction clearer, i.e.:
>>>
>>>   default_policy (unconfined)
>>>
>> I would like to get away from any implicit modes
> 
> Agreed.
> 
>>>> Fixing 10.
>>>>   We add an unconfined mode, it can be placed on any profile. (DONE)
>>>
>>> Can you be explicit and say what it means for a profile to be in
>>> unconfined mode? What are the exec transitions for it (i.e. '/** pix'
>>> or '/** pux')? Can it have additional restrictions in the form of deny
>>> rules, or other modifiers in the form of audit rules as well stricter
>>> (from a path dominance definition) exec transition rules?
>>>
>> It currently mimics the unconfined profile behavior 100%. That is no rules
>> are enforced, no denie are enforced, short circuiting is done and transitions
>> are pix
> 
> For documentation purposes, I'd like to see this expressed as an
> apparmor policy; e.g.
> 
>   profile unconfined_example {
>     capability,
>     dbus,
>     mount, umount, remount, # missing any others? Is there a bare
>                             # mount related keyword that covers these all?
pivot_root, is missing

and there isn't a mount related keyword to express all of these yet.

>     network,
> 
>     # do rlimits have an unrestricted all keyword? They're kind of an
>     # odd duck out here
> 
rlimits and I assume cgroups (when we add them) are indeed odd ducks. They
don't follow the usual default deny, instead its wide open unless the
resource limit is specified.

This is kind of bolted on but comes from the fact that we aren't actually
involved in their mediation once set up. Is all apparmor is doing is
setting up the environment and protecting against changes too it.

>     file,
>     /** pix,

also
change_profile,

I was thinking it might be good to have a keyword to cover both self directed
and exec based transitions but that is something that can be added later
after more thought

there will also be several other new rules types, dbus, signal, ptrace ...

I was thinking of a generic ipc keyword that could cover those

>   }
> 
> (substituting pux for pix if we decide that's the behavior we want.)
> 
I think pix is right, it allow different unconfined profiles to track their
own children

>> Note: that in this case pix and pux are different as the profile in question
>> may not be the default_policy profile.
>>
>> There is some wiggle room in the semantics but not much. If you want to enforce
>> deny rules you are in an enforcing mode.
> 
> Okay. What I wasn't clear on was whether it was strictly intended
> as the equivalent of the existing unconfined policy, or if it was a
yes its intended to be a non-enforcing policy, this plays into labels and crosschecks

> misnamed default_allow mode (as opposed to the implicit default_deny
> mode of our existing enforcing-mode policies) that could then be
> overridden with deny rules.
> 
nope its not meant to be a default allow mode.

> If that's the case, I'm not entirely convinced there's a whole lot
> of value of having multiple profiles in unconfined mode in a single
> namespace, except to serve as early boot placeholders for later
they serve as boot placeholders and generic labels

I know your not fond of not separating the domain and objects types
but in the model we have they are unified. The kernel is set up around
a unified type (selinux) and keeping them separate isn't worth it.

> replacement policies. If you squint and think of apparmor policies
> as a state machine, state minimization would collapse all of them as
> the transitions out of them would all be the same on the same exec
> events. Am I missing some other purpose?
> 
well it would only collapse them if they had the same transitions, that
is pux instead of pix. So unconfined servers 3 purposes

- the mode of labels without rules
- a means of having different non mediating profiles that track a set
  of tasks. This gives flexibility that can be leveraged in boot, policy
  generation, etc. I don't expect it will be used often but its nice
  to have the possibility
- a means of providing a simple targeted policy (our default)