[apparmor] Handling meta-read permissions

[Jamie Strandboge]

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.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20100809/6790244c/attachment.pgp