On 2016-01-11 18:27:24, Seth Arnold wrote: > On Mon, Jan 11, 2016 at 05:41:43PM -0800, John Johansen wrote: > > >> +Stacking another profile via aa_stack_profile() is permanent and the > > >> process is not > > >> +permitted to revert to the previous confinement context. Unlike > > >> +aa_change_profile(2), confined programs wanting to use > > >> aa_stack_profile() need > > >> +no special rules in their profile to stack a new profile since the > > >> operation > > >> +does not broaden the allowed permissions. > > > > I'm also afraid that this kind of rule might also allow these APIs to be > > > used by exploit code to unreasonably manipulate profile transitions in > > > ways that aren't expected by policy authors. > > > > > how so? > > > > the policy will have to allow stacking, and stacking is purely restrictive. > > If the profile allows the stack, then and only then can it take priority > > over the profiles exec transitions, just like with change_profile. > > Earlier in the manpage it was suggested that policy does _not_ have to > have syntax to allow stacking.
When authoring the man page, I decided to slip the bit in there about
policy not having to allow stacking since stacking can never broaden
permissions. I'm pretty sure John has always assumed that stacking would
require a rule in the profile.
>
> If the stacking is entirely under the control of the program and not
> influenced by policy (as suggested in this manpage) then the following
> attack is feasible:
>
> Presume we're running in a confined sshd-alike application. The profile
> for the sshd-alike includes the following rule:
>
> /bin/bash Px -> user_shell,
>
> The intention is that users are confined to a specific profile once they
> are authenticated, one that doesn't allow system administration tasks.
>
> If an exploit during user authentication is allowed to call
> aa_stack_onexec("administrator_shell");
> and this API call overrides the Px in the profile, then an exploit could
> bypass the restricted profile and get a profile that allows administration
> tasks.
Interesting and valid attack. I hadn't considered the possibility of
screwing up exec transitions with calls to aa_stack_profile().
> It would be sufficient to say that aa_change_onexec() can only _add_ to
> the profiles rather than replace profiles in order to prevent this attack.
Or we can go back to the idea of requiring rules in the profile to allow
stacking. I think stacking rules in the profile is probably the most
predictable option.
Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
