Le funzionalità di Linux (setcap) sembrano disabilitare LD_LIBRARY_PATH

Question

Io uso LD_LIBRARY_PATH per impostare il percorso di una determinata libreria utente per un'applicazione. Ma se ho impostato le capacità su questa applicazione

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication 

poi LD_LIBRARY_PATH sembra essere ignorato. Quando lancio il programma, Linux si lamenta di non riuscire a trovare una determinata libreria condivisa.

Immagino che ci sia un qualche tipo di protezione che si attiva, per impedire che applicazioni con diritti estesi vengano dirottate. C'è una soluzione?

Answer 1

Sì, è disabilitato per motivi di sicurezza.

Answer 2

Il man page per sudo spiega:

Si noti che il linker dinamico sulla maggior parte dei sistemi operativi rimuoverà variabili che possono controllare il collegamento dinamico dall'ambiente di eseguibili setuid, tra cui sudo. A seconda del sistema operativo , questo può includere RLD *, DYLD *, LD_ , LDR_, LIBPATH, SHLIB_PATH e altri. Questi tipi di variabili vengono rimossi dall'ambiente prima che sudo inizi anche l'esecuzione e, come tale, non è possibile per sudo conservarli.

Come this link explains, il meccanismo effettivo per farlo è in glibc. Se l'UID non corrisponde a EUID (come nel caso di qualsiasi programma setuid, incluso sudo), tutte le "variabili di ambiente non protette" vengono rimosse. Pertanto, un programma con privilegi elevati viene eseguito senza alterazioni.

Answer 3

Come già affermato in altre risposte, questo comportamento è destinato. C'è una sorta di soluzione alternativa se è possibile compilare (o almeno collegare) l'applicazione da soli. Quindi è possibile passare -Wl,-rpath <yourDynamicLibraryPath> a gcc o -rpath <yourDynamicLibraryPath> a ld e non sarà necessario specificare LD_LIBRARY_PATH affatto all'esecuzione.

Answer 4

La soluzione a questo problema su Linux è il seguente:

andare a directory $cd /etc/ld.so.conf.d/ creare un nuovo file $ touch xyz.conf aprire questo file utilizzando un qualsiasi editor $vi xyz.conf

Aggiungere la il tuo percorso di libreria dinamico in questo file riga per riga per esse il percorso è il seguente:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ allora non ci dovrebbero essere tre voci in questo file come segue: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

quindi salvare il file ed eseguire il seguente comando: $ldconfig

Tutte le operazioni sopra menzionate devono essere eseguite dal login root

Answer 5

Un'alternativa da considerare è quella di "correggere" una libreria condivisa ELF scarsamente compilata e/o eseguibile utilizzando patchelf per impostare il percorso. https://nixos.org/patchelf.html

ld.so.conf non è sempre la scommessa sicura. Funzionerà se qualunque cosa tu stia correndo è stata compilata correttamente. Nel mio caso, con un particolare prodotto Apache del fornitore appositamente confezionato, è stato compilato in modo insufficiente: non hanno nemmeno usato nomi di file .so unici quindi erano in conflitto con i nomi di file .so dagli RPM nei repository RHEL di base che fornivano alcune librerie comunemente usate piuttosto critiche . Quindi questa era l'unica opzione per isolare il modo in cui venivano utilizzati. L'uso di ld.so.conf contro quegli oggetti condivisi nel percorso della lib del venditore avrebbe spazzato via un sacco di cose, incluso yum, insieme agli errori di libreria condivisa glibc, a livello di sistema.