[apparmor] [RFC PATCH 1/1] libapparmor: Create man page for aa_stack_profile()/aa_stack_onexec()
Seth Arnold
seth.arnold at canonical.com
Tue Jan 12 02:27:24 UTC 2016
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.
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.
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.
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/20160111/e11df572/attachment.pgp>
More information about the AppArmor
mailing list