[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
<[email protected]>
http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
