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

[Florian Weimer]

* DJ Delorie:

> Yury Khrustalev <yury.khrustalev@arm.com> writes:
>> We might have to find another more generic way to deliver tunable
>> values that does not rely on environment variables and works for all
>> kinds of applications.
>
> Relying on environment variables *does* work for all kinds of
> applications, though.

It doesn't work for AT_SECURE binaries:

  Need a mechanism to disable glibc rseq for binaries with capabilities
  <https://inbox.sourceware.org/libc-alpha/62FC2BE3-1230-4E84-BE3A-98583B74A003@nutanix.com/>

> I'd like to take a moment to remind people that the "security" aspects
> of the global tunables are not "protect against bad actors" type of
> security we normally work with.  Global tunables are there to set a
> policy which supports the admin's policies.  Most tunables are not
> related to security at all, like malloc heaps or cpu features.  A few
> are, like shadow stacks.  They're still TUNABLES.  Globally enabling
> shadow stacks, for example, enhances overall security even if some
> applications can still disable it, but does not protect against local
> attacks.  There's nothing stopping a user from running a program that
> doesn't use our ld.so and not getting global tunables.  No program
> should RELY on tunables being one way or the other to operate (for
> example, if you need a global tunable to override a broken hwcap, you
> actually need a different fix ;).
>
> So the fact that a statically linked executable doesn't get global
> tunables applied really doesn't worry me much.

That I can agree with.  I'm fine with treating static linking as an
exceptional case that receives less support in general.

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

Thanks,
Florian