[apparmor] environment variables

[John Johansen]

On 01/11/2012 05:47 PM, Jamie Strandboge wrote:
> On Mon, 2011-11-14 at 16:30 -0800, John Johansen wrote:
>> On 11/14/2011 02:58 PM, Jamie Strandboge wrote:
>>
>>> Lastly, can you show me what the env rules would look like for the
>>> following use cases:
>>>
>>> 1. Say I don't care about any environment variables except FOOPATH. How
>>> can I say that all variables are allowed, including FOOPATH, except when
>>> FOOPATH=/home/*/evil?
>>>
>> env {
>>   **,
>>   deny FOOPATH=/home/*/evil,   # or perhaps you would prefer to filter
>> }
>>
>>> 2. Is there any concept of assigning a default value via the filter? Eg,
>>> if we match the filter, rather than filtering it, shove something sane
>>> in there? This seems rather icky but it does seem it would allow some
>>> flexibility.
>>>
>>> Basically, I'm trying to think how the environment variables handling
>>> can be used in a general purpose way (eg, as in a distribution).
>>>
>> No not in the current proposal.  That could be handy but setting values
>> will definitely require and exec handler, which is something we should
>> investigate more but maybe shouldn't be required for a first pass
>> implementation.
> 
> So I started looking into some of my profiling requirements for this a
> bit more this week and while I think that there are use cases for
> matching, filtering and pinning, from a profiling perspective I think
> pinning and filtering (so long as you can filter in such a way as to
> clear the env var completely) are the most interesting. As an initial
> implementation, either would be quite useful. As an alternative, simply
> having the ability to clear/unset an environment variable would be quite
> useful.
> 
So from an implementation pov
- matching is the easiest
- next by complete variable filtering/unsetting.
-  Partial filtering of a variables values is a little harder, and needs a
   good syntax that can distiguish between which parts of the variable
   are being matched and what part of the value when matched should be
   removed.
- setting a value would be next and will probably need a userspace helper
  so it can manipulate the env memory
- and most difficult is pinning as it requires identifying and saving
  off a value, and then setting it if it has changed.

I think a first pass at this will probably get the first two.