[apparmor] environment variables

[John Johansen]

On 11/08/2011 02:20 PM, Kees Cook wrote:
> 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.
> 
Right, and we could do it against the args too, but I think that is
in some ways more problematic

> 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.
> 
yeah that does seem to be the sanest solution

>> 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.
> 
possibly, but I could also see aare not being flexible enough.  I know we
have discussed it in the past wrt to file rules, and haven't found a pressing
need for more flexibility.  So I think the we probably should start out
with aare and see, if we hit cases where we need more flexibility.  If we
add pcre I think it would follow the previous proposal where pcre rules would
be anchored.
 eg.
    ^foo.*bar$

Basically if we used pcre there would have to be a way to indicate the match
was using pcre.  Using two different matching types with such a cue would
be madness.

>> 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.
> 
Well the match case was brought up because /me thinks filtering is going to
make some people want to wretch as we would be doing it in the kernel.  I am
just trying to get a feel for arguments for and against so we can choose
what is best and push for that.

>> 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.
> 
Nope your not misunderstanding.  This is me saying patching glibc is a possible
implementation but its crazy and I don't think we should go this route.
Currently secure exec is done in glibc, and I think this is a problem.  It
relies on linking against a revised glibc (or one of the many other alternates
to glibc).

>> 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.
> 
yep, you can thank Jamie for the idea.  It was brought up last week, as something
he would like.  He didn't propose it as kernel vars but, it could be done with
them.