This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, "Dmitry V. Levin" <ldv at altlinux dot org>
- Date: Thu, 30 May 2013 15:40:06 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <20130529053454 dot GB20323 at brightrain dot aerifal dot cx> <20130529235748 dot GA27200 at altlinux dot org>
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.