On 2016-01-14 00:46:24, John Johansen wrote:
> On 01/13/2016 08:08 PM, Seth Arnold wrote:
> > 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.)
> >
>
> I get the desire. My concern is that people will be confused by the
> subtle difference between requiring rules and not requiring rules.
>
> Another potential solution is if the target label is a subset of the
> current label then no rule is required.
>
> Eg.
> A -> A//&B # is subset
> A//&B -> A//&B//&C # is subset
> A//&B -> A//&C # NOT a subset
>
> for the transition that is delayed to exec time its label would have
> to be a subset of what is allowed by change_profile or exec rules.
>
> Note: in change_profile rules
> change_profile /exec -> target,
> means this change_profile is allowed only if an /exec is matched at
> exec time. This is currently supported, and results in a double
> pass at permission check. At the change_onexec api call
> change_profile /** -> target,
> is checked, because an exec match is not possible at this time,
> but we can check if target is in the set of what is allowed. At
> exec we then check the full rule and fail if the match is not
> done.
>
> Eg. say we are confined by A and have a rule
> px /** -> C,
>
> A -- stack_onexec --> A//&B # not allowed
> A -- change_onexec --> A # not allowed
> A -- change_onexec --> B&//C # allowed via px /** -> C
> A -- change_onexec --> B # not allowed
> A -- change_onexec --> C//&B # allowed via px /** -> C
> A -- change_onexec --> C # allowed via px /** -> C
>
> now say our rule set is
> px /** -> C,
> change_profile /** -> A,
>
> A -- stack_onexec --> A//&B # allowed via change_profile /** -> A
> A -- change_onexec --> A # allowed via change_profile /** -> A
> A -- change_onexec --> B&//C # allowed via px /** -> C
> A -- change_onexec --> B # not allowed
> A -- change_onexec --> C//&B # allowed via px /** -> C
> A -- change_onexec --> C # allowed via px /** -> C
>
> now say our rule set is
> px /** -> C,
> change_profile /** -> A//&B
>
> A -- stack_onexec --> A//&B # allowed via change_profile /** ->
> A//&B
> A -- change_onexec --> A # not allowed
> A -- change_onexec --> B&//C # allowed via px /** -> C
> A -- change_onexec --> B # not allowed
> A -- change_onexec --> C//&B # allowed via px /** -> C
> A -- change_onexec --> C # allowed via px /** -> C
>
> etc. I think that is enough to demonstrate the concept
> change/stack_onexec - could be allowed as long as it is a subset of
> what is allowed by the change_profile and exec rules.
>
> plane stack/change_profile allowed if it is subset of current
> confinement or what is allowed by change_profile rules.
>
> >> 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,
> >
>
> meh, the extra keyword doesn't do much for me, but I am all too familiar
> with the //& syntax so I am probably a poor judge. I'd like to here what
> other people think.I think the use of the 'stack' keyword here would make things confusing in other areas of the policy language where the 'stack' keyword could not be used but a we're still referring to a stack of profiles. Stealing one of the examples you posted above: px /foo/bar -> A//&B, We'd have to modify it to be something like: px /foo/bar -> A stack B, That's actually pretty clear. I think the real problem comes when the policy admin is reading the audit logs or a dev is using aa_getcon(2). The audit logs and aa_getcon() will not use the form 'A stack B'. The 'A//&B' form will be used in those cases. Translating between those things and the policy language would be a issue. Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
