Las capacidades de Linux (setcap) parecen deshabilitar LD_LIBRARY_PATH

Question

Utilizo LD_LIBRARY_PATH para establecer la ruta de una cierta biblioteca de usuario para una aplicación. Pero si fijo capacidades en esta solicitud

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication 

continuación LD_LIBRARY_PATH parece ser ignorado. Cuando lanzo el programa, Linux se queja de que no puede encontrar una cierta biblioteca compartida.

Supongo que hay algún tipo de protección, para evitar que las aplicaciones con derechos extendidos sean secuestradas. ¿Hay alguna solución?

Answer 1

Sí, está deshabilitado por razones de seguridad.

Answer 2

El man page para sudo explica:

Nota que el enlazador dinámico en la mayoría de sistemas operativos eliminará variables que pueden controlar la vinculación dinámica desde el entorno de ejecutables setuid, incluyendo sudo. Según el 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 conserve.

Como this link explains, el mecanismo real para hacer esto está en glibc. Si el UID no coincide con el EUID (que es el caso para cualquier programa setuid, incluido sudo), entonces se eliminan todas las "variables de entorno no seguro". Por lo tanto, un programa con privilegios elevados se ejecuta sin alteración.

Answer 3

Como ya se ha indicado en otras respuestas, este comportamiento está destinado. Existe algún tipo de solución 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 4

La solución a este problema en Linux es el siguiente:

ir al directorio $cd /etc/ld.so.conf.d/ crear un nuevo archivo $ toque xyz.conf abrir este archivo con cualquier editor de $vi xyz.conf

Añadir la su ruta de la biblioteca dinámica en este archivo línea por línea para, por ejemplo,Si la ruta es la siguiente:

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

continuación, guardar este archivo y ejecute el comando siguiente: $ldconfig

Todas las operaciones mencionadas anteriormente deben realizarse desde el inicio de sesión raíz

Answer 5

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

ld.so.conf no es siempre la apuesta segura. Funcionará si lo que está ejecutando se compiló correctamente. En mi caso, con un producto apache de un proveedor especialmente empaquetado, se compiló muy pobremente: ni siquiera usaban nombres de archivo .so únicos, por lo que entraban en conflicto con los nombres de archivo .so de los RPM en los repositorios RHEL base que proporcionaban algunas bibliotecas bastante comunes y comúnmente usadas . Entonces esta era la única opción para aislar cómo se usaban. El uso de ld.so.conf contra esos objetos compartidos en la ruta de acceso de la libra del proveedor habría hecho volar un montón de cosas, que incluía yum, junto con las fallas de la biblioteca compartida de glibc, en todo el sistema.