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

[John Johansen]

On 01/12/2016 01:23 PM, Jamie Strandboge wrote:
> 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?
> 

the no special rules part is not necessarily true, see the replay to Seth's
email that I have been (and still am) working on

the purely restrictive is true. Stacking is the intersection of the profiles
so if you are to be able to write to /proc/self/attr/current/ or 
proc/self/attr/exec, then after the stack both profiles must have that permission.

Hopefully my other email will explain this sufficiently. Not extending
permissions of a profile is delegation of authority and is beyond the scope
of the current discussion.