You are not logged in.

#1 2021-03-11 10:28:12

snack
Member
From: Italy
Registered: 2009-01-13
Posts: 861

Default dtags in Arch

I'm tracking down an inconsistent behavior of my application when compiled under different distributions. It seems that under Arch the -Wl,-rpath, linker flag will set an RPATH into the library, while under Ubuntu 20.04 the same flag results in a RUNPATH being set. So it seems to me that the linker have different defaults on the two distributions, maybe set at linker compilation time; is this reasonable/correct? Also, since RUNPATH seems to be the modern and more secure way (see e.g. this) I am wondering if there is a specific reason why RPATH is still the default on Arch.

Thanks in advance for any clarification.

Offline

#2 2021-03-11 11:30:11

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Default dtags in Arch

I think this can only be answered by archlinux devs and only a few of them use the forum .

Maybe post on the arch-general ML  ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2021-03-11 11:37:52

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: Default dtags in Arch

I know Fedora does not enable new dtags in their binutils either.  Not sure why Ubuntu has this early.

Offline

#4 2021-03-11 12:27:13

snack
Member
From: Italy
Registered: 2009-01-13
Posts: 861

Re: Default dtags in Arch

I did some research and I must say I'm really puzzled. If I'm correct the trend on Linux is towards RUNPATH, i.e. giving precedence to library folders specified by an environment variable (LD_LIBRARY_PATH) over those hard-coded in the binaries. Then on macOS it seems to be the opposite, namely disabling DYLD_LIBRARY_PATH in favor of DYLD_FALLBACK_LIBRARY_PATH togive precedence to rpath. Both approaches are motivated by the potential security issues with the other approach, and all seems to depend on which security hole (a malicious environment variable or write access to library folders encoded in rpaths) is perceived as more important...

Last edited by snack (2021-03-11 12:43:45)

Offline

#5 2021-03-12 00:33:56

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Default dtags in Arch

None of this has anything to do with security.

There are three (3) ways to define an additional library search path for a program or library, in order of priority:

- as an ELF binary attribute "rpath"

- as a confusing wrapper script setting the $LD_LIBRARY_PATH environment variable, which applies recursively across the execve() process tree

- as an ELF binary attribute "runpath"

The use of rpath is "deprecated", because it prevents users from using $LD_LIBRARY_PATH to set up local environments.

The use of $LD_LIBRARY_PATH is discouraged... by ISVs and other distributors, on the grounds that it's way too much of a blunt instrument as environment variables are inherited by child processes. And also because it complicates distribution if you have /usr/bin/progname-real and /usr/bin/progname and the latter is a shellscript that sets one *critical* environment variable before running the former.

The use of all 3 can introduce vulnerabilities if incompetent build systems add ridiculously random paths to the search path, and those paths aren't under control of the root account (i.e. somewhere in the /usr hierarchy). Your link to the wiki's security page does NOT call anything the "more secure way", it in fact calls it the *less* secure way while talking about "wildly nonsensical entries".

The typical vulnerable path is when the program is compiled in /home/eschwartz/svn-community/progname/src/progname-1.0/ and contains that path in the embedded entries or shell scripts. Then imagine, that you install the compiled program and run it from the /home/snack account. Well, guess what? Due to the incompetence of the build system (and my *personal incompetence, because I, eschwartz, failed to notice the namcap warning for insecure rpath), anyone running on your work system's multi-user workstation can request the username "eschwartz" and then add malicious stuff to their home folder, and suddenly, whenever you run the program, it starts looking in your colleague's home directory and loading random libraries.

Fortunately, your colleague is merely a humorous joker and those libraries merely cause the program to print ASCII My Little Pony art to the console, then exit. But, it could have been a lot worse, depending on the path and depending on who has access to it. It's also a good way for malware to add attack code that is much less likely to be detected than somewhere people actually look for insecure libraries, like... /usr/lib

And the thing is, it doesn't matter whether the vulnerable path got added by a shellscript or an ELF binary entry, or which "type" of ELF binary entry... it is still just as vulnerable.

...

All this being said, there is *modernity* to consider. The use of RUNPATH is more modern than RPATH, and it's recommended since it does not override the user's debugging attempts via $LD_LIBRARY_PATH and whatnot.

On the other hand, RUNPATH is incompatible altogether with setting an application bundle loader executable to a runpath of $ORIGIN/lib/ and then letting all libraries in ./lib/ look for their own dependencies in that selfsame directory. You need to set the runpath on every single library too. Which might not quite work out if some of them weren't built by you in the first place.

For that, you still need rpath, and never mind people setting $LD_LIBRARY_PATH


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#6 2021-03-23 15:24:36

snack
Member
From: Italy
Registered: 2009-01-13
Posts: 861

Re: Default dtags in Arch

Wow, thanks Eli for the very detailed answer (I think I got less than 50% due to my poor technical preparation on this topic) and sorry for the late reply but the notification email ended up in my spam folder. I ended up using neither RPATH nor RUNPATH, and always rely on environment variables both on Linux and macOS (I try to support both OSes with similar approaches). I find it more flexible, and my distribution needs are quite simple so I can handle the setting of env variables.

Thanks again and sorry for misinterpreting some information.

Offline

Board footer

Powered by FluxBB