[Bug dynamic-link/34360] Harden dynamic-loader resolution of $ORIGIN DST for setuid/setgid binaries

https://sourceware.org/bugzilla/show_bug.cgi?id=34360

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
The glibc security team reviewed and considered this not a security impacting
issue.

Normally we *ignore* $ORIGIN in setuid/setgid, except when specific rules are
met.

The path above meets the rules for ELF $ORIGIN use in setuid/setgid binaries.

That is to say that:

 * It begins with $ORIGIN and is followed by a directory separator.
 * It was evaluated and found to be rooted in a trusted directory
   e.g. /usr/lib.

It is a deployment mistake to leave a path in the directory resolution chain
that can be changed by an attacker.

Again, in short:

- The binary is trusted.
- The ELF DST use of $ORIGIN meets the rules for use in setuid/setgid binaries.

However, like the recent LD_PROFILE / LD_PROFILE_OUTPUT security report:
https://sourceware.org/bugzilla/show_bug.cgi?id=33797#c7 the use of $ORIGIN in
these cases where the path is not *explicitly* rooted in a trusted directory,
but instead resolves to, could be seen as a footgun that can trip up a
production deployment.

I'm open to alternative solutions that prevent the footgun, and that makes it a
hardening feature.

This is much less of an issue today with fs.protected_hardlinks being set to 1
for most production deployments (almost all distributions), but in theory a
vanilla kernel does ship with fs.protected_hardlinks set to 0 by default. I
consider it a reasonable worse case that in a multiuser enviornment you have
this protection enabled, otherwise you are in a single-user environment and
don't have this concern.

In summary:
- We don't consider this a security defect.
- There could be hardening around this to mitigate deployment defects.

-- 
You are receiving this mail because:
You are on the CC list for the bug.