[apparmor] environment variables

[Christian Boltz]

Hello,

Am Mittwoch, 9. November 2011 schrieb John Johansen:
> On 11/09/2011 03:00 PM, Christian Boltz wrote:
> > Am Mittwoch, 9. November 2011 schrieb John Johansen:
> >> On 11/09/2011 12:35 PM, Kees Cook wrote:
> >>> On Tue, Nov 08, 2011 at 03:24:27PM -0800, John Johansen wrote:

> > If an "exec" section exists, only env variables that are allowed
> > in the "exec" section _and_ in the target profile should be
> > allowed.
> just to be clear, you see this as an intersection of rules.  So at
> exec take the current profiles env rules, and apply them, and then
> apply the target profiles rules.

yes

> This could maybe actually work for the confined -> unconfined case in
> that the confined env rules would be applied, so you could do
> screening in the current profile.
> 
> With that said it is odd to apply current profile env restrictions on
> a target profile.  It would mean requiring the current profile to
> allow env variables that you only want in the target.  Basically you
> would have to bubble env variables back up the exec chain at least
> one level.

Looks like my proposal wasn't clear enough ;-)

Let's say we have /bin/foo calling /bin/bar, so their profiles could 
look like this:

/bin/foo {
    /bin/bar Px,
    exec /bin/bar {
        env PATH /usr/bin:/usr/sbin:*
        env DISPLAY :0
        env HOME
    }
}

/bin/bar {
    env PATH /usr/bin:/usr/sbin:/bin:/sbin:*
    env HOME
    env LANG
}

This would mean:
- no env restrictions for /bin/foo
- /bin/bar will see 
  - PATH if it matches /usr/bin:/usr/sbin:/bin:/sbin:* (which is the 
    more strict rule)
  - HOME
  - but not DISPLAY (even if it matches :0) because it's not allowed in 
    the target profile
  - and also not LANG because it's not allowed in the exec section of 
    the calling profile

That all said: Having an "exec" section for Px'd profiles should be an 
exception, and having no "exec" section should mean not to do env 
filtering by the calling profile (except what safe exec filters out, of 
course).

> > That leaves the question how exec sections for ix and Cx (and
> > lowercase px/ux) calls should be handled. Maybe they don't make
> > too much sense, OTOH just ignoring them would give users a false
> > sense of security. This basically means we have the choise
> > between honoring exec for all *x rules or to fail with a parser
> > error if exec is specified for ix or Cx.
> Right one of the open question is whether to apply the env rules for
> all execs or just safe execs like Px, Cx, Ux.

I'd say we should apply them on both if they are specified. The 
difference should be that the safe execs would filter out the most 
critical env vars as they do now, even if the target profile contains 
"env *".

In other words: Px, Cx and Ux should do the same as using
    deny env LD_PRELOAD
    deny env LD_LIBRARY_PATH
    deny env [...]
or shorter
    deny env @{whatever_safe_exec_filters_out}

We can add those deny rules to all profiles on the long term and maybe 
even get rid of safe exec [1] [2], but for now the backwards-compatible 
way proposed above would be the best IMHO.


Regards,

Christian Boltz

[1] basically safe exec means env filtering by the calling profile, and
    we seem to agree that filtering on the target profile is better

[2] maybe Ux is an exception again, but this could be solved with an
    "exec" section

-- 
Ich springe so oft aus dem Fenster, daß ich ein schnurloses
Telefon habe.                         [Ratti in suse-linux]