[apparmor] environment variables

[John Johansen]

On 11/10/2011 12:00 PM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 10. November 2011 schrieb John Johansen:
>> 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:*
> 
>> over directly attaching it to the matching rule
>>
>> /bin/foo {
>>      /bin/bar Px {
>>          env PATH /usr/bin:/usr/sbin:*
> 
>> or
>>
>> /bin/foo {
>>      /bin/bar Px  env {
>>          PATH /usr/bin:/usr/sbin:*
> 
>>
>> or even
>>
>> /bin/foo {
>>      /bin/bar Px  env=(
>>          PATH=/usr/bin:/usr/sbin:*
> 
> Separate exec sections would have the advantage that we could use one 
> for separate programs ("exec /bin/*").
> 
true which is nice but do we want to be able to override a generic filtering
done by the exec section?  So multiple exec sections (or filter or what ever
we call it).

  filter /** {
    env PATH /usr/bin:/usr/sbin:*
  }

  filter /foo/bar {
    env PATH /usr/bin
  }

This way we could define filter sets, and put them into standard abstractions
and override them if needed for specific execs.

Or possibly we could put the overriding filter on the exec rule it self if it
needs it.

  /bin/bar Px  filter {
    env PATH /usr/bin
  }

> That reminds me that we already have a similar syntax for child profiles 
> (including named transition) - what about just using that syntax and 
> putting only[1] env rules into it?
> 
I don't think so.  I understand the appeal but I see this as conflating two
separate things leading to problems.  Its kind of like the idea I had of using
generic profile transitions for the exec/filter block.

  /** Px {
    env PATH /usr/bin:/usr/sbin:*
  }

while this gives the generic filtering, it also directs all execs into a profile,
which if done right could still fail but could be confusing.

> This would mean
> 
> /bin/foo {
>     /bin/bar Ux,
> 
>     profile /bin/bar {
>         env PATH [...]
>     }
> }
> 
> Maybe it could even use named transitions:
> 
> /bin/foo {
>     /bin/bar -> cleanenv Ux,   # I hope I remember the syntax correctly
> 
>     profile cleanenv {
>         env PATH [...]
>     }
> }
>
yeah I think this really is conflating two separate things, and worse, for
none Ux transitions it brings in the propagation of target profile envs
into the parent profile, because for none Ux transitions this basically
works out as applying current and target profile env rules again.

Unless you meant that the env profile would only contain env rules, but
then we get duplicate profiles for the case where say you want a child
profile and env filtering

> The only disadvantage is: it might be confusing when used with px/Px.
> But that's still less confusing than having to learn another syntax that 
> is specific for env vars. Additionally, Px'ed programs will/should have 
> the env rules in the target profiles in most cases.
> 
Hrmm, I tend to think of its more confusing, but perhaps thats just me.

So far I have been convinced that the majority of the filtering should
be done in the profile, but a per rule helper is worth having, whether
its expressed as an 'exec' block, or on the rule.

I am leaning to using the rule as I think that will be less confusing
in that you don't have to know to look for the filter block, and I
think that the per rule over ride won't be commonly used except for
on Ux.  I also think we can dump most of what we want in a variable or
include so it would become something like

/bin/foo {
  #include <safe-env>

  /bin/bar Ux filter { #include <ux-safe-env> }
}

or some such