[apparmor] unconfined mode and 'file' keyword

[Steve Beattie]

On Fri, May 17, 2013 at 01:55:07PM -0700, 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,

Bah, I mean "link /** -> /**," of course.

> (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/



> -- 
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor


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