[apparmor] environment variables

[Christian Boltz]

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

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

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

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

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

@{MOST_CRITICAL_ENV_VARS} should contain the list that is used for Px, 
Cx and Ux.

I'd even allow the audit keyword:

    audit env EDITOR,   # log for editor statistics

> Should it use aare syntax, or perhaps pcre syntax?

Both would be ok for me.

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


Regards,

Christian Boltz
-- 
Not mentioned in the `known features'-list so far...
[found on https://bugzilla.novell.com/show_bug.cgi?id=152068]