[apparmor] environment variables

[John Johansen]

On 11/10/2011 04:33 AM, Christian Boltz wrote:
> 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).
> 
Ah okay, so basically this is env filtering in the profile and at the
rule level.

So do you see an advantage of using an exec section

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

over directly attaching it to the matching rule

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

or

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

or even

/bin/foo {
     /bin/bar Px  env=(
         PATH=/usr/bin:/usr/sbin:*
         DISPLAY=:0
         HOME=**
     )
}


>>> 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 *".
> 
makes sense at least if their is an exec section instead of tying directly
to the rule.

> 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.
> 
Right we need to remain backwards-compatible

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