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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 06/10/23 09:41, Siddhesh Poyarekar wrote:
> On 2023-10-06 08:25, Zack Weinberg wrote:
>>> 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.
> 
> Hmm, I don't remember anything like this recently (but my memory is worse than my airplane flying skills), but something like that would be an interesting data point and further confirmation that we need to get rid of SXID_IGNORE and SXID_NONE.  In any case, I can't see a good reason anymore to keep these levels, especially if we drop memory tagging, malloc tuning and malloc debugging tunables from SXID_IGNORE. If memory tagging needs to persist across setxid programs then there needs to be a different way, maybe through systemwide tunables[1] that DJ is working on, or maybe even ELF markup.
> 
> Adhemerval has taken this patchset and is going to build on it to rip it all out, so we'll hopefully resolve all of this together.

I think the less contiguous change would to keep with the blacklist of
environment variables, since changing to whitelist will change the
current semantic (and add possible user-visible breakage), ignore any
tunable on AT_SECURE binaries (as some Linux distributions are already
doing [1]), add GLIBC_TUNABLES to unsecvars (so if AT_SECURE binaries
want to set any tunable, they should it explicit), and remove the 
requirement of duplice the GLIBC_TUNABLES tunable parsing (which
some memory allocation failure).

Yes, security hardening tunables won't be applied for AT_SECURE binaries,
but I think opt-in security features that have performance implications
should done by system administrator instead of relying on users.

[1] https://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=5d1686416ab766f3dd0780ab730650c4c0f76ca9