[apparmor] unconfined mode and 'file' keyword

[Steve Beattie]

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

> > 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?
    network,

    # do rlimits have an unrestricted all keyword? They're kind of an
    # odd duck out here

    file,
    /** pix,
  }

(substituting pux for pix if we decide that's the behavior we want.)

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

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

-- 
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/b75624c7/attachment.pgp>