[apparmor] unconfined mode and 'file' keyword

Fri May 17 22:52:59 UTC 2013

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.

> >   }
> > 
> > (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.

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.

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

-- 
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/20130517/be59a63b/attachment-0001.pgp>