Linux capabilities (setcap) seems to disable LD_LIBRARY_PATH

Question

I use LD_LIBRARY_PATH to set the path of a certain user library for an application. But if I set capabilities on this application

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

then LD_LIBRARY_PATH seems to be ignored. When I launch the program, Linux complains that it cannot find a certain shared library.

I guess that there's some kind of protection kicking in, to prevent applications with extended rights from being hijacked. Is there a workaround?

Bookish

Answer 1

Yes, it's disabled for security reasons.

Bookish

Answer 2

As already stated in other answers, this behavior is intended. There is some kind of workaround if you can compile (or at least link) the application yourself. Then you can pass -Wl,-rpath <yourDynamicLibraryPath> to gcc or -rpath <yourDynamicLibraryPath> to ld and you won't have to specify LD_LIBRARY_PATH at all on execution.

Mascot

Even with -rpath Linux prevents loading shared libraries after calling setcap. – Stretcher

Answer 3

The solution to this problem on linux is as follows:

go to directory $cd /etc/ld.so.conf.d/ create a new file $touch xyz.conf open this file using any editor $vi xyz.conf

Add the your dynamic library path in this file line by line for e.g. if your path is as follows:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ then there should be three entries in this file as follows: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

Then save this file and execute the following command: $ldconfig

All the above mentioned operation need to be performed from root login

Flaring

And yum will be broken. – Bust

Answer 4

The man page for sudo explains:

Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of setuid executables, including sudo. Depending on the operating system this may include RLD*, DYLD*, LD_, LDR_, LIBPATH, SHLIB_PATH, and others. These type of variables are removed from the environment before sudo even begins execution and, as such, it is not possible for sudo to preserve them.

As this link explains, the actual mechanism for doing this is in glibc. If the UID does not match the EUID (which is the case for any setuid program, including sudo), then all "unsecure environment variables" are removed. Thus, a program with elevated privileges runs without alteration.

Milkfish

This is all very well, but setcap doesn't change UID or EUID. It does add capabilities ("elevated permissions"). – Palatinate

Answer 5

An alternative to consider is to "correct" a poorly compiled ELF shared library and/or executable using patchelf to set the rpath. https://nixos.org/patchelf.html

ld.so.conf is not always the sure bet. It will work if whatever you are running was compiled properly. In my case, with a particular specially packaged vendor's apache product, it was compiled so poorly: They did not even use unique .so filenames so they conflicted with .so filenames from RPMs in the base RHEL repositories that provided some pretty critical commonly used libraries. So this was the only option to isolate how they were used. Using ld.so.conf against those shared objects in the vendor's lib path would have blown away a lot of stuff, that included yum, along with glibc shared library failures, system-wide.

Earthward

note that you'll have to rerun your setcap commands on the edited binary. Notwithstanding that, this is the most useful answer here - especially if a vendor has a misconfigured build pipeline – Bust