This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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. > - 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. -- ldv
Attachment:
pgpQGQco8PPf7.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |