[apparmor] environment variables

[Kees Cook]

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?

> >> 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?

> 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.

> >> 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.

> >> 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. :)

-Kees

-- 
Kees Cook