Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 2023-10-05 14:31, Zack Weinberg wrote:
> On Thu, Oct 5, 2023, at 9:59 AM, Szabolcs Nagy wrote:
>> The 10/05/2023 08:55, Siddhesh Poyarekar wrote:
>>> The current unsetenv logic is well reasoned IMO; the tunables layer made it
>>> complicated and it ought to be sufficient to just remove that.  But that
>>> would require dropping the memory tagging tunable from SXID_IGNORE and
>>> erasing GLIBC_TUNABLES by putting it in unsecvars.h.
>>
>> i think it is broken to rewrite env[] that is passed by
>> the kernel. but since glibc always did this i guess it's
>> fine.
> 
> I think the CVE that prompted this discussion demonstrates that it's *insecure*
> to allow children of setxid processes to inherit any environment variable that is
> considered insecure to consult in the setxid process itself.

I don't completely disagree with the conclusion below, but the CVE that 
prompted this discussion doesn't say anything about environment 
inheritance because the vulnerability had nothing to do with environment 
processing and inheritance.  The issue there is limited to complex 
parsing of a particular environment variable in a setxid context and the 
main lesson there IMO is to keep any kind of processing to a bare 
minimum in a setxid context.

Processing for environment inheritance (specifically, cleaning out 
unsecvars) is fairly stable code that has stood the test of time.  It 
makes sense like you suggest below, to make it an inclusion list rather 
than an exclusion list, but IMO that's a separate hardening exercise 
from ripping tunables out of the setxid context.

> I also think we ought to be talking about a very short *whitelist* of environment
> variables that are allowed to survive execve() of a setxid binary -- off the top
> of my head, TERM, LANG, LANGUAGE, LC_*, and maybe *nothing else* -- and putting
> that list into the kernel itself.
> 
> zw
> 

Thanks,
Sid