On Fri, 04 Feb 2022 at 02:23:54 +0000, Seth Arnold wrote: > does this represent a security problem?
"It depends". (This answer is not specific to CMake, it's equally valid for any build system.) If the RPATH or RUNPATH points to a trusted directory where write access would require root-equivalent privileges, such as somewhere below /usr, then it's not a problem. Some packages have to do this in order to access private shared libraries, which sounds like a contradiction, but isn't really. Some libraries are not sufficiently API- or ABI-stable to be suitable to place them in the global search path for the OS as a whole, but do need to be shared between a closely cooperating group of programs, either within a single package or in several tightly-coupled packages. For example, lots of small programs in the systemd package are linked to /lib/systemd/libsystemd-shared-250.so, which contains code that is shared between those programs but is not a stable public API. Statically linking that shared code would have resulted in a separate partial copy in every program, which would have made the package much larger, so instead it is a private shared library; and to make that work, the programs have a RUNPATH pointing to /lib/systemd. This RUNPATH is not a security problem with systemd, because to be able to exploit it to make these programs execute arbitrary code, an attacker would need to be able to write to /lib/systemd - but if the attacker can write to /lib/systemd (or, more generally, /usr or /lib), then system integrity has already failed. Having a RUNPATH set to /usr/lib/ganesha looks like it is similar to the systemd case. If it's intentional, then it's almost certainly fine. The situation where a RPATH or RUNPATH *does* represent a security problem is when the RPATH or RUNPATH points to a directory that might become attacker-controlled. For example, if the RUNPATH of a program "foobar" is set to its build directory in /tmp, perhaps /tmp/foobar_1.0_59PnHH, then an attacker could create that directory, put their malicious code into it, and wait for the victim to run foobar. Similarly, if the RUNPATH is /home/fred/builds/foobar-1.0, then that isn't a practical problem for most people, but if you happen to have an untrusted local user whose home directory is /home/fred, it becomes a security vulnerability on that particular system. There is a third situation referenced by https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html, which is not a security problem, but is a reproducibility problem. It's common for executables and libraries to be given a temporary RUNPATH pointing to the location of shared libraries in the build directory, so that unit tests can be run before the package is installed without needing to set the LD_LIBRARY_PATH (in Autotools, this is the --disable-fast-install option; in CMake, it seems to be the default). CMake removes the RUNPATH just before installation, so it doesn't become a security problem, but that's too late to stop it from affecting the build-ID - and the *length* of the build directory can also affect the contents of the binary, because when RUNPATHs are removed, it is done by overwriting them with zeroes in-place, leaving a run of zeroes with the same length as the removed RUNPATH. smcv
