This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Tunables-related security regression
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Date: Mon, 23 Jan 2017 11:38:54 +0100
- Subject: Tunables-related security regression
- Authentication-results: sourceware.org; auth=none
I filed
<https://sourceware.org/bugzilla/show_bug.cgi?id=21073>
because tunables change the behavior when filtering insecure environment
variables such as MALLOC_CHECK_.
We have three different kinds of environment variables:
(1) variables which are removed when AT_SECURE is active
(2) variables which are ignored when AT_SECURE is active
(but they are passed to subprocesses, where AT_SECURE
may not be in effect)
(3) variables which are not treated in any special way
LD_DEBUG is in category (1), HESIOD_CONFIG is in (2), and TZ is in (3).
Currently, enabling tunables moves MALLOC_CHECK_ from category (1) to
category (2), which is unexpected. This would be quite easy to fix,
except that the same functionality is available as part of
GLIBC_TUNABLES, which is currently in category (2) as well.
I think we need to reintroduce the filtering of MALLOC_CHECK_, and
re-add the rewriting of the GLIBC_TUNABLES.
We probably should put GLIBC_TUNABLES into category (1) if tunables are
*not* active (currently, it's in category (3) because glibc does not
know anything about tunables if they are disabled).
Thanks,
Florian