Stop using absolute rpaths

[brson]

Followup to #5219. Per that issue rpaths are frowned on by linux distros. Absolute rpaths are supposed to be worse than relative rpaths (I'm not clear on why at the moment), and they are probably relatively easy to get rid of. Nominating.

[thestinger]

For an example of why an absolute path is bad, consider building a library in a home directory or perhaps /tmp. The compiled binary now ends up with /home/foo/build or /tmp/build-14a29fp as a path to load libraries. It's very easy to deploy this library without thinking about the relative rpath and expose a significant vulnerability.

It's true that this is also possible with relative ($ORIGIN-based) paths, but it's far less likely. A relative path can also be useful in a deployed package, while an absolute path is rarely correct and at best redundant.

Linux distributions usually lint for insecure rpaths, rather than all rpaths. So, an $ORIGIN-based path will be considered okay as long as it doesn't point outside of the directories owned by the package and they do not provide write permissions to non-root users.

[pnkfelix]

Accepted for 1.0, P-backcompat-lang.

[lucab]

No, relative $ORIGIN-based rpaths are also problematic from a security POV. See CVE-2009-0876 for a real world exploitation PoC due only to rpath usage.

[thestinger]

Sure, but having no absolute rpaths is better than having both $ORIGIN and absolute paths. The absolute paths are a bigger problem because they're always wrong if you install a Rust library or binary as a package. At least the $ORIGIN-based ones can be right, and often are.

[o11c]

I don't know if you can avoid all absolute rpaths if you configure with a custom BINDIR and LIBDIR. It should be possible if you only change PREFIX, or only change BINDIR and LIBDIR within prefix (i.e. ${PREFIX}/lib64).

Think especially about the relatively common case where a rust package is installed by a user in ${HOME}. This absolutely needs an rpath ... and in the case there BINDIR=/bin and LIBDIR=/.local/lib, gets kind of hairy.

In fact, now that I think about it, my ~/bin is a symlink anyway, so relative rpaths wouldn't work.

As far as I understand it, rpaths are only a security problem when running executables with a set*id bit or setcap bits.

Oh, and about the "install multiple deps when you can't write to root" - the solution to that sounds like a sysroot (which == DESTDIR).

So:
compile libfoo, install with DESTDIR=/tmp/build, the actual lib is in /tmp/build/usr/lib
compile hellofoo with sysroot=/tmp/build

[thestinger]

That's not when rpaths are meant to be used. A user can set LD_LIBRARY_PATH to add a directory to the library loading path, just like they can modify PATH. A relative rpath is used to give a program a hidden application-specific library path that's not meant to be included in the system library search paths via ld.so.conf.d.

@o11c: It is not just a security issue with setuid binaries. Rust binaries will have rpaths based on their build directory opening up the ability for non-root users to inject code when other users run the binary, like root. Rust won't be included in Fedora or Debian if it's making this kind of security faux pas - rpaths should be opt-in.

[o11c]

Well, what I always heard about LD_LIBRARY_PATH was "don't use it; use rpath instead". Particularly, asking users to set LD_LIBRARY_PATH globally just to be able to install rust packages as user is wrong. When installed as user, absolute rpaths should definitely be used.

Yes, it's wrong to have an rpath pointing to the build directory, but that's not the same as it being wrong to have an absolute rpath at all.

For the virtualbox $ORIGIN attack, I would hope that root can be trusted not to accidentally run someone else's hard link to the binary. Therefore, it should be secure to have two rpaths: an absolute one to the install directory (where bindir and libdir may have no relation), and a relative one to the build directory (where the equivalent of bindir and libdir are known) for testing.

[thestinger]

Particularly, asking users to set LD_LIBRARY_PATH globally just to be able to install rust packages as user is wrong. When installed as user, absolute rpaths should definitely be used.

I don't understand why you would say this. It's totally fine to set LD_LIBRARY_PATH for a specific user, to load libraries from a user-controlled directory. It's really not much different than adding a local directory to PATH, as you can even mask system binaries that way (which is not a bad thing). Unlike an absolute rpath, it won't require rebuilding everything if the directory changes or the user's home directory is moved - for example, if the username needs to be changed.

I am obviously not suggesting that it be done globally. The /etc/ld.so.conf file and /etc/ld.so.conf.d directory exist for system-wide library directories controlled by root.

Yes, it's wrong to have an rpath pointing to the build directory, but that's not the same as it being wrong to have an absolute rpath at all.

It's insecure to add an absolute rpath by default. I don't know of any other compiler doing this. I doubt that the Ubuntu PPA is removing this insecure rpath, for example.

For the virtualbox $ORIGIN attack, I would hope that root can be trusted not to accidentally run someone else's hard link to the binary. Therefore, it should be secure to have two rpaths: an absolute one to the install directory (where bindir and libdir may have no relation), and a relative one to the build directory (where the equivalent of bindir and libdir are known) for testing.

I'm not talking about hard links. Adding rpaths by default with the compiler means files installed to root are going to accidentally end up with insecure rpaths. Other compilers are not doing this by default, so it makes Rust's behaviour very surprising. There's no such thing as an rpath on Windows so Rust can never provide a consistent, predictable behaviour if it uses this hack.

[thestinger]

Rust won't be allowed in Fedora and Debian until this issue is fixed, and their policies are not going to change. At most, they'll patch this out of the compiler and Windows won't be the only platform behaving differently.

[brson]

My understanding is Debian is likely to make at least temporary exceptions for Rust's remaining infidelities, but we should still keep trying to work toward a model that doesn't use rpath.

[thestinger]

Static linking is already used by default and the build process no longer needs rpaths. There's nothing blocking stripping it all out today and having users set them manually if they want them, as other languages do. It's not a technical issue anymore.

[o11c]

There is absolutely nothing insecure about an rpath that is writable by the same set of users (i.e. just root) who can write to the binary itself (barring the set_id thing). There is *nothing_ fundamentally wrong with rpath. Just don't use it wrong. Neither Debian nor Fedora has an absolute ban on rpath, and Rust fits quite neatly into the explicitly permitted case.

And there are very real cases where static linking simply cannot be used. One particular case I hit recently: when you need to link to an internal C shared library that is not in the default library path. I have to compile my rust library as crate type dylib and add the rpath myself. But anybody linking to my rust library shouldn't have to know about internals - they only need the rpath to my library, which rustc currently happily provides.

Everything should Just Work. If rpath isn't added by rust itself (which can be done securely), you'll just end up with a bunch of ad-hoc scripts adding it in all the packages, which is infinitely harder to make secure.