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

[Zack Weinberg]

On Thu, Oct 5, 2023, at 3:11 PM, Siddhesh Poyarekar wrote:
> On 2023-10-05 14:31, Zack Weinberg wrote:
>> On Thu, Oct 5, 2023, at 9:59 AM, Szabolcs Nagy wrote:
>>> 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.

I may have misunderstood the CVE or mixed it up with another one.
I thought there was a recent CVE in which a SXID_IGNORE environment
variable was inherited by a child process, and that child process was
rendered vulnerable to further exploitation because it honored that
variable.

> 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.

Agreed.

> 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.

Also agreed.

zw