[apparmor] environment variables

[John Johansen]

On 11/08/2011 02:05 PM, Christian Boltz wrote:
> Hello,
> 
> Am Montag, 7. November 2011 schrieb John Johansen:
>> 1. Matching
>>
>> The idea here is to extend the exec matching rules, with a conditional
>> match.
>>
>> Eg. something like
>>
>>    env={LD_PRELOAD=/usr/bin/*,FOO=bar} /bin/foo Ux,
> 
> And now imagine how long the line will be if you specify 50 environment 
> variables... ;-)
> 
yes that is a problem

>> 1a. Should environment variable matching be on the rule, profile or
>> both? Placing environment matching on the profile seems to make sense
> 
> Placing env matching on the profiles makes sence.
> Additionally, it will keep the profiles more readable (one line per 
> variable).
> 

>> until you consider the Ux case, as there is no profile to match
>> against.
> 
> Indeed, that opens an interesting can of worms.
> OTOH, if something is called Ux, it intentionally doesn't have a profile 
> and "wants to run unsecured". So why should we restrict the environment 
> variables for it (besides the most important Ux already filters out)? 
> env support for Ux isn't a a must-have IMHO.
> 
Well Ux is supposed to filter out environment variables so that we can
some what safely run the application unconfined.  The problem is that we
can't currently do this because secure exec is not scrubbing enough
environment vars.

For Ux to be considered even remotely usable we need to control the
environment, it is in fact the main driver for controlling environment
variables.  Specifically we are talking about transitions from a confined
state to an unconfined state, we wouldn't be controlling the environment
variables of an unconfined to unconfined transition.

I do think the profile seems like the sane place to have the rules, but
part of the question really is can we come up with situations where
we are going to want to have the flexibility of having these at the rule
level.

For Ux the rule is currently the only way to express this.  That doesn't
mean that we couldn't add some kind of stub entry like a profile to
define additional environment filtering for Ux transitions

  eg.
  exec /foo/bar {
    env PATH /usr/bin:/bin:*
    env EDITOR

  }

and then a Ux rule would use that, but it wouldn't be used as a profile.

Or any other solution that can be found, as long as we can get better
control of the env vars especially for confined to unconfined transitions

>> 1b. Should failing to match result in a failed exec or should it fall
>> back, and try continuing the match against a more generic, or
>> alternate target.
> 
> I'd say use the simple solution: remove any environment variables that 
> don't match the pattern.
> 
so filtering (ie. option 2 below)

>> 1c. What should the match expression look like, should it be a white
>> list, or a black list.  
> 
> A whitelist is the more secure option.
> 
yep and combined with deny rules you can simulate a black list

> I'd propose a syntax like this:
> 
>     env PATH /usr/bin:/bin:*   # PATH must begin with /usr/bin and /bin
>     env EDITOR   # allow any EDITOR
> 
> Nevertheless we could combine it with the deny keyword to allow a 
> blacklist-like behaviour
> 
>     env *,   # allow all environment variables, except...
>     deny env SSH_AGENT_PID,
>     deny env EDITOR /usr/bin/emacs,   # let the editor wars begin...
>     deny env @{MOST_CRITICAL_ENV_VARS},
> 
yeah defining multiple entries is important, the only question is whether
here is whether per profile is flexible enough.  /me doesn't know

> @{MOST_CRITICAL_ENV_VARS} should contain the list that is used for Px, 
> Cx and Ux.
> 
yep we would need define some variables to help manage and make this sane

> I'd even allow the audit keyword:
> 
>     audit env EDITOR,   # log for editor statistics
> 
oh I like that

>> Should it use aare syntax, or perhaps pcre syntax?
> 
> Both would be ok for me.
hehe, in generally I think both is desirable.  I fear when it comes to
environment matching that aare probably won't be flexible enough

> 
>> 1d. Compatibility.  Should the env conditional matching be able to be
>> dropped by the kernel if it doesn't support it and still match a
>> profile/exec rule.
> 
> yes, it should
> 
>> 2. Environment filtering
>>
>> Environment filtering would be like extending the existing secure
>> exec, except with policy involvement, so the environment variable
>> filtering could be defined per rule or profile.
>>
>> It has many of the same questions as Matching.
>>
>> 2a. Should environment variable filtering be on the rule, profile or
>> both?
> 
> per profile
> 
>> 2b. Should environment filtering be a white list or a black list?
> 
> see above ;-)
> 
>> 2c. Should it use aare, or pcre syntax, or maybe multiple entries.
> 
> same as above
> 
>> 2d. Should env filtering be backwards compatible.
> 
> yes, please.
> 
>> 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 vote for KISS ;-)
> 
Generally I agree, part of the question is whether we can actually get
a filtering solution upstream.  Hence the questions about a pure matching
approach, does it by us enough, and are there any reasons we would
want both, ...