This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Tunables-related security regression
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Date: Mon, 23 Jan 2017 15:30:38 +0000
- 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 Mon, 23 Jan 2017, Zack Weinberg wrote:
> On Mon, Jan 23, 2017 at 5:38 AM, Florian Weimer <fweimer@redhat.com> wrote:
> >
> > 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).
>
> 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*.
I tend to agree. Now can you persuade POSIX of that
<http://austingroupbugs.net/view.php?id=922>? (It's *also* true as
discussed in that bug report that the cases where such variables are
unsafe are cases where the AT_SECURE process should be using a whitelist,
not a blacklist, to set up the subprocess environment, but that shouldn't
disallow useful practical security measures such as removing unsafe
environment variables.)
--
Joseph S. Myers
joseph@codesourcery.com