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. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
