[apparmor] environment variables

[Kees Cook]

I think this is good to finally address. I mean, even just looking at
the execve() call itself, it takes path, args, and env. It wouldn't be
totally crazy to extend the matching to include env in the matching.

On Mon, Nov 07, 2011 at 11:13:49PM -0800, John Johansen wrote:
> 2. Environment filtering
> 
> Environment filtering would be like extending the existing secure exec, except
> with policy involvement, so the environment variable filtering could be defined
> per rule or profile.
> 
> It has many of the same questions as Matching.
> 
> 2a. Should environment variable filtering be on the rule, profile or both?

It seems like "both" would be the place to do it.

> 2b. Should environment filtering be a white list or a black list?

I'd say, it's a whitelist. Everything not mentioned is stripped out.

> 2c. Should it use aare, or pcre syntax, or maybe multiple entries.

This is a bit painful. Seems like mixing pcre into the rules would confuse
things for profile-writers.

> 2d. Should env filtering be backwards compatible.

Yes, ignore it without kernel support. It's the only way to not break the
world on updates. Isn't this what has been done with other things?

> 3. Hybrid
> 
> It would be possible to have a hybrid of matching and environment filter if
> there is a compelling need and we can devise a reasonable syntax.

I'm not sure I see a strong need for the matching case. I can _imagine_
them, but I'm not sure it's worth the effort if there isn't a expressed
need. Filtering, on the other hand, is actively needed.

> 4. Implementation
> 
> The likely implementation seems to be in the kernel in the bprm hook called
> during exec.  Environment filtering could be achieved by extending secure
> exec in the libc loader.  However this solution is problematic in that it
> relies on all binaries to be linked against the revised loader which
> in many cases is not an assumption that can be made.

I'm not sure what you mean about the libc loader bit there. Surely you
don't meant modifying glibc itself? Why not just filter it directly in the
kernel? I must be misunderstanding something.

> Another point is that with kernel variables we could support better matching
> of values that change per session but should be static during the session.
> For example the dbus session bus, shouldn't change for the duration of the
> session, so a kernel var could be set when the session is setup, and then
> that value would be matched against for all processes in the session.

Hunh. That's a very interesting idea, "sticky" environment variables.

-Kees

-- 
Kees Cook