[PATCH v5 4/4] Add system-wide tunables: Filters

[Adhemerval Zanella Netto]

On 27/02/26 00:04, DJ Delorie wrote:
> Florian Weimer <fweimer@redhat.com> writes:
>>> Relying on environment variables *does* work for all kinds of
>>> applications, though.
>>
>> It doesn't work for AT_SECURE binaries:
> 
> True, but those are normal binaries that system-wide tunables can
> influence.  If we had a binary that was AT_SECURE *and* static *and*
> required a tunable, we would not be able to support that.
> 
>>> For "true" security, you'd need something at the kernel level that can
>>> be forcibly applied to all processes, regardless of how they run.
>>> Tunables are not that thing.
>>
>> They can be for AT_SECURE binaries if we want that.
> 
> True, but not as significant a statement as you'd think.  Any admin who
> can set the AT_SECURE bit is already on the 'inside' of the security
> wall.  The question is, can tunables be used to implement security
> policy as defined by admins, but applying to users, for *all* programs?
> No, it can't, because users can just use a different loader.
> 
> Thus, I think it's important to keep in mind that tunables might be able
> to assist in securing a system, but should not be relied on for
> enforcing security.
> 
I think is unexpected from an user point of view that tunables are supported
through environment variables, but system-wide values are not *enforced*.

And while I agree with the idea of system-wide tunable not being a protection
against bad actor, the idea of system-wide is to provide a way to enforce
security *hardening* without relying on the environment variable as a way to
accomplish it.

Since some kernel ABI hardening is opt-in in userland rather than enforced by
the kernel, we can just make it consistent within glibc. For instance, for the
security tunables glibc.cpu.aarch64_bti and glibc.cpu.aarch64_gcs, I would
expect that the system-wide tunable would allow admins to ensure that binaries
built against glibc always use BTI (and not silently enable it only if all
modules support it), and GCS (which is not enabled by default even when the
process has the attribute).

If we decide not enforce it for static binaries, users will probably either
hack its support into (like Firefox did for DT_RELR) or just avoid using
glibc (which is already the usual way). In either case, it does not improve
security or system-wide usage.