On 01/11/2016 06:17 PM, Tyler Hicks wrote: ... > 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. > + Is this true? Won't the profile need write access to /proc/self/attr/current and/or /proc/self/attr/exec like so:
owner @{PROC}/@{pid}/attr/{current,exec} w,
Unfortunately, since we don't yet have kernel variables for @{pid}, this rule
(which is as strict as I can make it while still allowing the (presumed) access
for stacking) means I would be able to stack on other processes' confinement,
no? Or am I missing something behind the scenes where the kernel will have an
implied rule that you can always write to your own process' current and exec,
but no others?
...
> +Using aa_stack_profile() and related libapparmor functions are the only way
> to
> +ensure compatibility between among varying kernel versions. However, there
> may
> +be some situations where libapparmor is not available and directly
> interacting
> +with the AppArmor filesystem is required to stack a profile.
Typo: 'between among'
--
Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
