Re: [PATCH][v2] Add dynamic linker support for $EXEC_ORIGIN.

[Mike Frysinger <vapier at gentoo dot org>]

On Thursday 12 December 2013 17:13:39 Brooks Moses wrote:
> Updated to address Paul's comments about using getsauxval().
> 
> The $ORIGIN rpath token expands to the directory containing the true
> copy of the application executable -- which is to say, if the executable
> is invoked through a symlink, that symlink will be resolved in the
> $ORIGIN substitution.
> 
> In some cases, such as symlink farms backed by cloud storage filesystems
> where the resolved path encodes effectively-arbitrary storage data, it
> is much more useful to have a rpath token that points to the
> non-expanded, as-called version of the executable path.  This patch adds
> the $EXEC_ORIGIN token for this purpose, resolving to the executable
> path as passed to execve().
> 
> One potential security risk of such a token expansion is that, although
> copying a setuid/setgid executable (to change its $ORIGIN) loses the
> setuid/setgid bit, creating a symlink does not -- and so a user could
> inject arbitrary code into a setuid/setgid executable that references
> $EXEC_ORIGIN by creating an appropriate symlink.  In order to slam the
> door shut on this security risk, this patch simply prohibits the use of
> $EXEC_ORIGIN in setuid/setgid binaries.

this probably should be documented somewhere in glibc (beyond just the code 
itself).  a quick scan of the manual though doesn't seem to turn up any 
discussion of topics like rpath or $ORIGIN, so i guess the assumption is that 
we follow the standard ELF conventions.  which leads into the next point ...

shouldn't it also be coordinated (at least loosely) with the linker and ELF 
ABI peeps ?  they already fully document (and in some cases implement) the 
semantics of DT_RPATH/DT_RUNPATH, so having glibc add its own (undocumented) 
extensions doesn't seem like a good idea.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.