Consensus: Tuning runtime behaviour with environment variables.

[Carlos O'Donell]

On 05/29/2013 07:57 PM, Dmitry V. Levin wrote:
> On Wed, May 29, 2013 at 01:34:54AM -0400, Rich Felker wrote:
>> On Wed, May 29, 2013 at 12:56:50AM -0400, Carlos O'Donell wrote:
> [...]
>>> I'd like to drive some consensus around the idea of using
>>> environment variables to tune runtime behaviour in glibc.
> [...]
>> - Any settings which could cause a conforming application which works
>>   correctly with the default settings to stop working correctly should
>>   be ignored completely when the program is suid or AT_SECURE is set
>>   in the aux vector.
> 
> In case of AT_SECURE processes, unfortunately, there is no guarantee that
> a non-default functionality controlled by environment variables would not
> be abused for privilege escalation (see CVE-2010-3847 and CVE-2010-3856 as
> an illustration).
> 
> To minimize the risk, no new environment variables should affect glibc
> behaviour of AT_SECURE processes (and programs they execute) unless these
> privileged executables explicitly opted in.

I like that. I've hardened the langauge to read:

"An application with AT_SECURE set will ignore all environment 
variable tunables and will not pass them automatically to their 
children (that doesn't preclude the AT_SECURE application 
setting an env var for the child or using the API to tune 
performance for itself)."

>> - The namespace for glibc tuning variables should be clearly defined
>>   in such a way that they can be mechanically removed from the
>>   environment without having to worry that future additions will be
>>   missed by the stripping code.
> 
> I maintain a hardening patch that extends UNSECURE_ENVVARS and replaces
> most of getenv calls with __libc_secure_getenv, so enforcing a namespace
> for these environment variables would certainly ease the burden of
> maintenance.

A strict namespace will certainly be maintained.

Cheers,
Carlos.