[apparmor] Handling meta-read permissions

[John Johansen]

On 08/09/2010 04:55 PM, Jamie Strandboge wrote:
> On Thu, 2010-07-29 at 15:43 -0700, John Johansen wrote:
>> Currently AppArmor provides a pass on meta-read permission, closing this hole lead
>> to bug https://launchpad.net/bugs/599450.  We considered fixing this through profile
>> changes but this would require granting read access for every directory and file
>> along PATH variables that are probed.  This would require opening up profiles far
>> more than the old behavior of implicitly granting meta-read permissions.
>>
>> Going forward the user space read permission will grant both read and meta-read
>> permissions.  But there will be cases when we don't want to grant full read
>> permissions.
>>
>> we have two options
>> * Require explicitly specifying meta-read permission rules.  This will require
>>   expanding current profiles, to enable them to work.
>>   eg.
>>      /foo/  r,
>>      /foo/* meta-r,
>>
>>      /bar/**/ r,
>>      /bar/**/* meta-r,
>>
>> * Granting read permissions on a directory implies granting meta-read permissions
>>   on the files in the directory.  Basically if you can read the directory contents
>>   you can stat the files in it.
>>
>>   eg. (cover permissions granted by above example)
>>      /foo/  r,
>>      /bar/**/ r,
>>
>>   This will not remove the need to be able to specify meta-r, but it should take
>>   care of most cases, with out requiring profile modification.
>>
> 
> While conceptually I prefer the former, considering all the profiles out
> there, I think the latter is the way to go. While we as upstream and
> distributions can adjust profiles for our users, we will break
> home-grown and modified profiles pretty badly if we go with the former. 
> 
> However, I like being able to fine-tune access, so perhaps we can do at
> least one more, such as:
> 
> /foo/ r,
> /bar/**/ r,
> /baz/ nometa-r,
> /baz/* meta-r,
> 
> This at least gives us the option of moving to a finer-grained access.
> For completeness, also allow taking away meta-r:
> /foo/ r,
> deny /foo/bar meta-r, 
> 
> All the 'meta-r' and 'nometa-r' isn't all that pretty, but hopefully you
> get the idea.
> 
Basically I agree with you that this is the way to go and that the
meta-r nometa-r is UGLY.  Actually I was hoping for a better proposal on
what to name extend permissions.  I want to make them available at
the rule level, but with the common case of r, w etc expanding out to
the extended list internally.