[apparmor] environment variables

[John Johansen]

On 11/09/2011 12:42 PM, Kees Cook wrote:
> On Tue, Nov 08, 2011 at 03:00:57PM -0800, John Johansen wrote:
>> 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
> 
> Yeah, especially since the perspective we're looking at this from is
> that of a toolkit or language doing unexpected things out from under the
> application itself with environment variables. But I guess some toolkits
> are responsible for parsing commandline options (Xlib). Maybe this needs
> some further thinking?
> 
certainly but argv filtering is something that can be considered separately
from env filtering.

>>>> 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$
> 
> Yeah. And if we added pcre, maybe it could be done everywhere then, not
> just with env vars?
> 
yeah, that was the original proposal.  You could do
  ^/bin/.*$ rw,

etc.

>> 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.
> 
> Right.
> 
>>>> 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.
> 
> What's so bad about doing env filtering in the kernel? There isn't any
> other place to safely do it without having finished a full exec load.
> 
Well be sides mucking around in userspace memory nothing.  I think its the way
to go, but I can just imagine some people not liking it :)

>>>> 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.
> 
> Ah, yeah. Totally agreed. :)
> 
>> 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).
> 
> Is this something other than what I'm thinking? I've understood your use of
> "secure exec" to mean glibc's cleaning up of sensitive LD_* variables when
> running set-id.
> 
Right, just trying to reiterate the objection to it, secure exec relies on the
loader implementing it so it seems broken by design to me.

>>>> 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.
> 
> Yeah. It's like DNS pinning. Only with env vars. My mind is blown. :)
>