[apparmor] Fwd: environment variables

[John Johansen]

On 11/14/2011 07:45 PM, Tetsuo Handa wrote:
> Reply to post on Tue Nov 15 00:30:10 UTC 2011
>> filter PATH=/home/*,
>> deny PATH={**:,}/home/bad{:**,}
> 
> How do you handle "PATH=/./home/bad" and "PATH=/home/./bad" and
> "PATH=/home/bad/" cases? Unlike file's pathname calculated from dentry/vfsmount
> pair, environment variable's value cannot be normalized.
> 
right, I can see a few ways to handle them
1. You could explicitly match against them, ie. your rule allows for it
2. You could explicitly filter or deny rules containing them
     deny PATH=**/./**,  or **/.{.,}/** for both . and ..
3. You could explicitly filter out path segments containing them
     still toying with what the syntax should look like, but it will necessitate changing the
     current proposal some
4. You could explicitly filter out sections of paths containing them ie. /./ just gets removed
     hopefully the same solution for 3 will allow this
5. You could call a userspace exec handler and let it deal with normalizing the path, etc.

I would like the ability to trigger an exec handler, then the kernel would do the matching
that it can but if it hits something that would need an exec handler it could fall back to
it.  I haven't really been discussing the exec handler yet as I think we can built the kernel
side of the filtering first, and as long as we plan it right it should be straight forward to
extend it after with an exec handler.

> Also, implicitly removing environment variables can cause target application to
> use defaults. For example,
> 
>   CC=mygcc make
> 
> might use gcc if CC was implicitly removed.
> 
> Rather, rejecting execve() seems to be safer.

possibly it would depend on the environment variable, that is why we want to provide
both filtering and deny options.  It is possible that we change the default from being
a filter to a deny.