Las capacidades de Linux(setcap) parecen deshabilitar LD_LIBRARY_PATH

shared-libraries linux-capabilities

Question

Utilizo LD_LIBRARY_PATH para establecer la ruta de una determinada biblioteca de usuarios para una aplicación. Pero si configuro capacidades en esta aplicación

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

entonces LD_LIBRARY_PATH parece ser ignorado. Cuando ejecuto el programa, Linux se queja de que no puede encontrar una determinada biblioteca compartida.

Supongo que se está implementando algún tipo de protección para evitar el secuestro de aplicaciones con derechos extendidos. ¿Hay una solución?

Answer 1

Como ya se dijo en otras respuestas, este comportamiento es intencional. Hay algún tipo de solución alternativa si puede compilar (o al menos vincular) la aplicación usted mismo. Luego puede pasar -Wl,-rpath <yourDynamicLibraryPath> a gcc o -rpath <yourDynamicLibraryPath> a ld y no tendrá que especificar LD_LIBRARY_PATH en absoluto en la ejecución.

Answer 2

La página del manual para sudo explica:

Tenga en cuenta que el enlazador dinámico en la mayoría de los sistemas operativos eliminará las variables que pueden controlar la vinculación dinámica del entorno de los ejecutables setuid, incluido el sudo. Dependiendo del sistema operativo, esto puede incluir RLD *, DYLD *, LD_ , LDR_ , LIBPATH, SHLIB_PATH y otros. Este tipo de variables se eliminan del entorno antes de que sudo comience a ejecutarse y, como tal, no es posible que sudo las preserve.

Como explica este enlace , el mecanismo real para hacer esto está en glibc. Si el UID no coincide con el EUID (que es el caso de cualquier programa setuid , incluido sudo ), se eliminan todas las "variables de entorno no seguras". Así, un programa con privilegios elevados se ejecuta sin alteración.

Answer 3

La solución a este problema en linux es la siguiente:

vaya al directorio $cd /etc/ld.so.conf.d/ cree un nuevo archivo $ touch xyz.conf abra este archivo con cualquier editor $vi xyz.conf

Agregue la ruta de su biblioteca dinámica en este archivo línea por línea, por ejemplo, si su ruta es la siguiente:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ entonces debe haber tres entradas en este archivo de la siguiente manera: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

Luego guarde este archivo y ejecute el siguiente comando: $ldconfig

Todas las operaciones mencionadas anteriormente deben realizarse desde el inicio de sesión de root

Answer 4

Sí, está desactivado por razones de seguridad.

Answer 5

Una alternativa a considerar es "corregir" una biblioteca compartida y / o ejecutable ELF pobremente compilada usando patchelf para establecer el rpath. https://nixos.org/patchelf.html

ld.so.conf no siempre es la apuesta segura. Funcionará si lo que está ejecutando se compiló correctamente. En mi caso, con un producto de apache particular de un proveedor especialmente empaquetado, se compiló tan mal: ni siquiera usaron nombres de archivos .so únicos, por lo que entraron en conflicto con los nombres de archivos RPM en los repositorios de RHEL base que proporcionaban algunas bibliotecas de uso bastante crítico. . Así que esta fue la única opción para aislar cómo se utilizaron. El uso de ld.so.conf contra esos objetos compartidos en la ruta de acceso del lib del proveedor habría volado muchas cosas, que incluían yum, junto con fallas de la biblioteca compartida de glibc, en todo el sistema.