[apparmor] unconfined mode and 'file' keyword

[John Johansen]

On 05/17/2013 03:52 PM, Steve Beattie wrote:
> On Fri, May 17, 2013 at 02:32:40PM -0700, John Johansen wrote:
>> On 05/17/2013 01:55 PM, Steve Beattie wrote:
>>> On Thu, May 16, 2013 at 03:33:52AM -0700, John Johansen wrote:
>>>> On 05/16/2013 02:20 AM, Steve Beattie wrote:
>>>>> 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
> 
> The reason I asked to document the equivalent policy is that, if we
> go ahead with the ability to modify the default_policy, it's likely
> people will want to create replacement policies that are generally
> equivalent to unconfined but removing a subset of privileges.
> 

right, sorry if I gave the impression that this wasn't a good idea. Documenting
this is something that is critical! thank you for pointing out we haven't
done so already.

>>>   }
>>>
>>> (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.
> 
> Ah right, the generic labels. I keep forgetting them because I have yet
> to write a real apparmor policy that includes them yet. (Sorry.) That's
> a valuable use case.
> 
> (And yes, I think conflating subject and object labels is a namespace
> commingling mistake, but abstractly you have subject <-> subject
> communication and so policies will want to grant the ability to
> communicate with other policies. But my bias was not the reason for
> me forgetting this use case.)
> 
>>> 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.
> 
> This is really neither here nor there to the discussion at hand
> and you're more hip to the state of the art in state minimization
> algorithms than I am, but as 'ix' is a state transition to itself,
> it would be a poor minimization algorithm that didn't recognize that
> a set of states that all went back to themselves for the same input
> and to the same external states for the rest of the possible input
> could not be compressed into a single state.
> 
sorry not quiet what I meant. It comes down to whether the profile
itself defines a unique state or the mode.  That is given

  A (unconfined) { }
  B (unconfined) { }

is A to be considered distinct from B? Or is it potentially different
if the mode (unconfined) is used as the state determiner this is
trivially minimized to a single state.

If A and B taken into account, then you have two choices. They are
strictly always separate, or there is a potential for minimization
if they have the same transitive closure.

  pix vs. pux in the transitive closure case is different.

Anyways yes minimization could collapse these if that is what was
desired. Again it really comes down to the dynamic potential of
replacing these, thus changing them and making them non equivalent

> But having different labels for processes that we can then mediate
> on whether confined processes can communicate with a subject with
> that specific label is a useful thing.
> 
yep

>> 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)
> 
> Agreed.
> 
> 
>