Per què nosuid impedeix que un auxiliar de VPN es converteixi en root

El xifratge del disc i un muntatge nosuid sonen com a variacions de la mateixa idea, i no hi tenen cap relació. Un protegeix les dades en repòs, i l’altre decideix si el nucli respectarà un bit de privilegi en el moment que un programa arrenca. Un auxiliar que no arriba a la identitat que espera s’està queixant del segon. La suposició que el primer n’és el responsable fa que la gent reinstal·li clients que mai no havien estat espatllats.

Dues propietats no relacionades

El xifratge del disc respon qui pot llegir els blocs quan la màquina és apagada. Una opció de muntatge respon què farà el nucli amb els bits de mode d’un fitxer quan algú l’executa. Res del primer no limita el segon, i un portàtil totalment xifrat pot muntar un sistema de fitxers amb totes les restriccions al seu lloc.

Llegir-los com una sola propietat és el que produeix la teoria que una llar xifrada impedeix l’accés root. Aquesta teoria sobreviu perquè els dos símptomes apareixen a la mateixa màquina, no perquè comparteixin una causa.

Què suprimeix realment la transició

La referència d’execve descriu com un executable amb set-user-ID canvia la identitat efectiva del procés nou per la del propietari del fitxer. La mateixa pàgina llista les condicions que suprimeixen aquesta transició i l’equivalent per als identificadors de grup: un paràmetre no_new_privs, un sistema de fitxers muntat amb nosuid i un procés que s’està traçant. Les capacitats del fitxer s’ignoren sota les mateixes condicions. Aquestes quatre regles cobreixen gairebé tots els informes d’aquest tipus.

Aquesta llista explica per què el mode que imprimeix ls no és mai tota la història de l’autorització. No us diu quina condició va causar un missatge de fallada concret, i l’aplicació pot estar informant d’una operació de credencials no relacionada amb les mateixes paraules. Anoteu el programa exacte, el llançador i la seqüència d’errors abans de treure cap conclusió.

Identifiqueu l’executable que va instal·lar el paquet suportat, el seu propietari, la seva ruta real i la política del sistema de fitxers que el conté. Una còpia en una carpeta de baixades no és l’auxiliar instal·lat, digui el que digui el seu mode.

Què no s’ha de fer

Posar bits set-user-ID en un binari no verificat i moure’l d’un lloc a un altre fins que la restricció desaparegui no és una reparació. Substitueix una política que no enteníeu per un privilegi que no podeu auditar, i la mateixa tècnica aplicada a un auxiliar és una via d’escalada ben coneguda. Treure nosuid d’un muntatge és pitjor, perquè afecta tots els programes d’aquell sistema de fitxers, no només un.

La via suportada és la instal·lació documentada de l’auxiliar o del servei del client, feta per un administrador, que col·loca el binari on la política l’espera. Així es manté un sol mecanisme de privilegi en lloc de dos.

Confirmeu el context d’inici real

Després d’una correcció autoritzada, executeu l’auxiliar tal com el producte l’executa i no des d’una shell de root. Un èxit com a root no demostra res sobre el camí que fa un usuari normal, i la diferència entre aquests dos contextos és exactament allò de què anava la fallada.

Després confirmeu l’operació de xarxa per a la qual existeix l’auxiliar. Un auxiliar que arrenca però no pot configurar la interfície ha mogut el problema una etapa més enllà, no l’ha resolt.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

Anoteu les opcions de muntatge i la propietat de l’auxiliar en la mateixa nota. Si no, la següent persona que depuri això tornarà a començar la teoria del xifratge.