This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Tunables-related security regression
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 23 Jan 2017 16:22:00 +0530
- Subject: Re: Tunables-related security regression
- Authentication-results: sourceware.org; auth=none
- References: <e9cbe93c-e788-f67c-bfce-4c8feda220e0@redhat.com>
On Monday 23 January 2017 04:08 PM, Florian Weimer wrote:
> 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
Thanks for the context.
> I think we need to reintroduce the filtering of MALLOC_CHECK_, and
> re-add the rewriting of the GLIBC_TUNABLES.
Ack, I'll fix this.
> 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).
By not active, do you mean where the source is not configured with
tunables support? That seems pointless since any glibc that did not
have tunables would come under that category, i.e. anything before 2.25.
Siddhesh