[apparmor] [RFC PATCH 1/1] libapparmor: Create man page for aa_stack_profile()/aa_stack_onexec()

[Seth Arnold]

On Tue, Jan 12, 2016 at 03:10:28PM -0800, John Johansen wrote:
> now lets look at the stack on exec case. The stack addition is delayed
> until exec.  The current profile will have the stack added on top, the
> question is when and how.
> 
> 1. stack_onexec as stack + change_onexec: stack is computed immediately
>     but the transition is delayed until exec (this overrides any
>     transitions and is how Tyler described it)
>   A -- stack_onexec B -- exec --> A//&B
> 
> 2. stack_onexec, stack delayed until exec applied pre-exec transitions
>   A -- stack_onexec B -- exec apply stack -- A//&B -- exec trans --> C//&D
> 
> 3. stack_onexec, stack delayed until exec applied post-exec transitions
>   A -- stack_onexec B -- exec trans -- C -- apply stack --> C//&B
> 
> each is a viable definition and each could have their uses.

This is perfect; I had been envisioning #2 before this series of emails.
I didn't like #1 much when I read it in Tyler's proposed manpage. I think
I prefer #3 now that I've had some time to think about this.

> Example 3: is similar to example 2 except B does not require a domain
>   transition. It can be thought of stack on top of what ever current is
>   after exec.
> 
>   Rules wouldn't be required in this model but still might be desirable.

I think I don't like requiring rules for this approach. Two of the uses of
stacking that I envision are to reduce privileges without requiring
editing of distro-supplied profiles. Editing the distro-provided profiles
to explicitly describe the stacking may be more complicated than just
re-writing the distro profiles in the first place and avoiding stacking.
(Yeah, the future delegation work could provide a different solution to
my problem.)

> Whether to go with 1, 3 or both depends on use cases, and how these are
> implemented. So lets look at the exec side some more. Because exec rules
> are also going to pickup the ability to specify stacking. Note the syntax
> here is not final but sufficient for the discussion.
> 
> exec rules allow naming a profile to transition to
>   px /foo/bar -> A,
>   px /** -> A,
> 
> this will be extended to support specifying an explicit stack
>   px /foo/bar -> A//&B,
>   px /** -> A//&B,
> 
> however we may want to be able to specify the stack based off the target
> profile, this works for
>   px /foo/bar -> /foo/bar//&B,
> 
> but does not work for the rule with globbing because there can be
> multiple targets matched.
>   px /** -> ??//&B,
> 
> we can get around this by either introducing a special variable
>   px /** -> @{TARGET}//&B,
> 
> or extending the stacking syntax a little to mean use the target and
> what is specified.
>   px /** -> &B,   # leading & specifies use target and stack B
> 
> however neither of these syntaxes are sufficient (for globbing rules) to
> specify the final confinement when we want the execed process to have
> current confinement and B. We can extend each syntax to support this.
> 
>   px /** -> @{SELF}//&B,
>   #Note: @{PROFILE} is not correct as the task may already have
>   #      a stack of profiles, so it is current confinement
> 
> and
>   ix /** -> &B,			# notice ix instead of px

These all feel fairly subtle. The explicit stack rules are clear enough,
but the leading & is probably too easy to overlook. The @{SELF} variable
might be too hard to explain vs the @{profile_name} variable.

How about:
  px /** -> stack &B,  ix /** -> stack &B,
or:
  px /** -> stack B,  ix /** -> stack B,

> Now to the matter of whether stacking rule in the profile is required.
> 
> 1. requires a rules otherwise it can be exploited, as Seth has
>    already pointed out.
> 
> 3. doesn't require a rule but it probably should use them, mostly
>    so for consistency with 1.

I'm less sure about this. I haven't figured out what I'd like the policy
to look like for the different kinds of stacking that I've envisioned,
especially since some of the reasons is because I want to use "upstream"
policy unchanged but still tighten it due to administrative needs or
personal preferences.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160113/416180cb/attachment.pgp>