De ce nosuid împiedică un ajutor VPN să devină root
Un director personal criptat și o montare nosuid sunt proprietăți diferite. Ajutorul are nevoie de o cale de instalare de încredere și de un context de lansare care îi respectă bitul de privilegiu.
Criptarea discului și o montare nosuid sună ca variante ale aceleiași idei, și nu au nicio legătură. Una protejează datele în repaus, iar cealaltă decide dacă nucleul va respecta un bit de privilegiu în momentul în care un program pornește. Un ajutor care nu ajunge la identitatea pe care o așteaptă se plânge de a doua. Presupunerea că prima este responsabilă îi trimite pe oameni să reinstaleze clienți care nu au fost niciodată stricați.
Două Proprietăți Fără Legătură
Criptarea discului răspunde la cine poate citi blocurile când mașina este oprită. O opțiune de montare răspunde la ce va face nucleul cu biții de mod ai unui fișier când cineva îl execută. Nimic din prima nu o limitează pe a doua, iar un laptop complet criptat poate monta un sistem de fișiere cu toate restricțiile la locul lor.
Citirea lor ca o singură proprietate este ceea ce produce teoria că un director personal criptat împiedică accesul root. Teoria supraviețuiește pentru că cele două simptome apar pe aceeași mașină, nu pentru că ar împărtăși o cauză.
Ce Suprimă de Fapt Tranziția
Referința execve descrie cum un executabil cu set-user-ID schimbă identitatea efectivă a noului proces în cea a proprietarului fișierului. Aceeași pagină enumeră condițiile care suprimă această tranziție și echivalentul lor pentru identificatorii de grup: o setare no_new_privs, un sistem de fișiere montat cu nosuid și un proces care este urmărit. Capacitățile fișierului sunt ignorate în aceleași condiții. Acele patru reguli acoperă aproape orice raport de acest fel.
Acea listă explică de ce modul tipărit de ls nu este niciodată toată povestea autorizării. Nu spune care condiție a cauzat un anumit mesaj de eroare, iar aplicația poate raporta o operațiune de acreditare fără legătură cu aceleași cuvinte. Notați programul exact, lansatorul și secvența erorilor înainte de a trage o concluzie.
Identificați executabilul instalat de pachetul acceptat, proprietarul acestuia, calea reală și politica sistemului de fișiere care îl conține. O copie într-un director de descărcări nu este ajutorul instalat, orice ar spune modul ei.
Ce Să Nu Faceți
Să puneți biți set-user-ID pe un binar neverificat și să îl mutați până dispare restricția nu este o reparație. Înlocuiește o politică pe care nu ați înțeles-o cu un privilegiu pe care nu îl puteți audita, iar aceeași tehnică aplicată unui ajutor este o cale de escaladare bine cunoscută. Scoaterea nosuid dintr-o montare este mai rău, pentru că afectează fiecare program din acel sistem de fișiere, nu doar unul.
Calea acceptată este instalarea documentată a ajutorului sau serviciului de către client, efectuată de un administrator, care plasează binarul acolo unde politica îl așteaptă. Astfel rămâne un singur mecanism de privilegiu în loc de două.
Confirmați Contextul Real de Lansare
După o corecție autorizată, rulați ajutorul așa cum îl rulează produsul, și nu dintr-un shell root. Un succes ca root nu demonstrează nimic despre calea pe care merge un utilizator obișnuit, iar diferența dintre aceste două contexte este exact ceea ce privea eșecul.
Apoi confirmați operațiunea de rețea pentru care există ajutorul. Un ajutor care pornește dar nu poate configura interfața a mutat problema cu o etapă mai departe, nu a rezolvat-o.
findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper
Notați opțiunile de montare și proprietatea ajutorului în aceeași notă. Altfel, următoarea persoană care depanează acest lucru va repeta teoria criptării de la început.