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: Zack Weinberg <zackw at panix dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 23 Jan 2017 18:30:32 +0530
- Subject: Re: Tunables-related security regression
- Authentication-results: sourceware.org; auth=none
- References: <e9cbe93c-e788-f67c-bfce-4c8feda220e0@redhat.com> <CAKCAbMh71Ahe9Dve1w=MqwKYUS18HCtfoBiNmoyukb-omPOJVQ@mail.gmail.com>
On Monday 23 January 2017 06:07 PM, Zack Weinberg wrote:
> We should probably not have category (2) at all. If a variable is
> unsafe for direct use in an AT_SECURE process, it is almost certainly
> also unsafe for use in a non-AT_SECURE process *when invoked as a
> subprocess of an AT_SECURE process*.
>
> "Rewriting of GLIBC_TUNABLES" also makes me very nervous. I
> understand that this is an umbrella variable containing both things
> that are safe and things that are unsafe, but it's better to do as
> little parsing of untrusted input as possible. Do we really _need_ to
> be able to tune AT_SECURE programs?
We do if we are obliged to maintain compatibility - all of the other
MALLOC_* envvars are ignored in AT_SECURE, but are passed on to
non-AT_SECURE subprocesses. I suppose if the threat perception of
passing on envvars from AT_SECURE to non-AT_SECURE is high enough, it
could be a case for simply dropping category (2) completely.
Siddhesh