Re: Tunables-related security regression

[Zack Weinberg <zackw at panix dot com>]

On Mon, Jan 23, 2017 at 10:30 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 23 Jan 2017, Zack Weinberg wrote:
>>> 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.)

I don't think I have anything to say there that hasn't already been
said.  "The application should apply a whitelist" is a logically valid
rebuttal to any argument of the form "variable X is exploitable in a
setuid-root program that does setuid(0) followed by invocation of a
child process". :-/

(With http://austingroupbugs.net/view.php?id=188 in mind, what would
you think of a `get_secure_child_environ()` extension, that returns an
environment vector suitable for use as the third argument to `execve`,
consisting of a _whitelisted_ subset of the process's environment?
Assuming we can agree on what the whitelist should be.  ... PATH may
be a headache.  The vector itself (not the strings it points to)
should be malloced.)

zw