Re: [committed 2/2] tunables: Terminate if end of input is reached (CVE-2023-4911)

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 2023-10-04 08:20, Adhemerval Zanella Netto wrote:
> I think it would be best to avoid changing AT_SECURE binaries semantic
> through tunables or even environment setting (/etc/suid-debug).  It
> means adding back GLIBC_TUNABLES to unsecvars (so even non AT_SECURE
> binaries won't see GLIBC_TUNABLES), do not process GLIBC_TUNABLES for
> AT_SECURE (including malloc mcheck), and dropping any ill-formed
> GLIBC_TUNABLES strings (so first parse and only apply well-formatted
> ones).

I started that process with this patchset[1] that's probably the most 
contentious (or maybe not) issue.  If we get consensus on that, we can 
move to drop GLIBC_TUNABLES support completely for AT_SECURE in 2.39.

> This would allow to just remove the tunables_strdup altogether,
> simplifying the code a lot.  It also means that any security tunable
> (such as the glibc.mem.tagging) would also stop appling to AT_SECURE,
> but I think we should stopping giving users to change secure binares
> semantics even in this way.

We won't get to drop tunables_strdup; it's still needed to make a copy 
to delimit tunable values.  We can drop all the twiddling under the 
__libc_enable_secure though.

> And I don't think we should make this changes iff we have a a trusted
> system-wide tunable.

Ack, I can live with that.

Thanks,
Sid

[1] https://patchwork.sourceware.org/project/glibc/list/?series=25312