[apparmor] environment variables

[John Johansen]

On 11/09/2011 03:00 PM, Christian Boltz wrote:
> Hello,
> 
> 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:
> 
>>>> Interesting, would you envision them being applied together, or
>>>> as an intersection. ie.  Do the profile and file rules
>>>> accumulate to increase the set of environment vars that are
>>>> passed, or do they intersect reducing the set.> 
>>> Hm, you caught me. I hadn't thought this through. :)
>>>
>>> I guess I was thinking about it from the Ux perspective, but in
>>> really pondering it, I think probably it would be most sensible
>>> to do it only from the profile side.
>>
>> okay so the question becomes how do you envision specifying this for
>> Ux binaries then. This is where I get stuck with doing at the profile
>> level, as the transition to any given binary, may or may not be Ux,
>> Px etc.  ie.  The same binary could be running both confined and
>> unconfined, have had different transitions etc.
>>
>> I proposed something like
>>   exec /foo/bar {
>>     env PATH /usr/bin:/bin:*
>>     env EDITOR
>>
>>   }
> 
> BTW: This looks like a good idea.
> 
>> in a reply to cboltz, but I am not sure that feels right either,
>> perhaps a better keyword than exec.  Something indicating this is
>> only do when transitioning from confined to unconfined would fix my
>> issues.
> 
> Maybe the "exec" section shouldn't be restricted to Ux ;-)
> 
Oh I wasn't proposing that.  It should be part of regular profiles as
well.  I was just musing on how to specify env restrictions for the
specific case of confined to unconfined transitions.

> I'd prefer to specify the allowed env variables in the target profile  
> because it should know best what makes sense, and avoids that we need 
> similar rulesets in several calling profiles.
> 
Right

> Nonetheless allowing to have an "exec" section for Px could make sense 
> to place additional restrictions on the env variables. 
yep

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

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.

Also note that due to the nature of env vars they are only being filtered
at exec time.

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