Butonul VPN are nevoie de sudo: restrângeți regula, validați politica
Un buton de pe desktop nu este un motiv pentru root fără parolă. Verificați dacă managerul de rețea poate face asta, restrângeți o singură comandă, apoi validați întreaga politică sudo.
Butonul VPN funcționează pentru administrator și eșuează pentru toți ceilalți, așa că cineva adaugă o linie în sudoers. Acea linie supraviețuiește de obicei problemei pe care trebuia să o rezolve și acordă adesea mai mult decât are nevoie butonul. Înainte de a edita politica, verificați dacă proprietarul acceptat al conexiunii poate deja face treaba. Cele trei condiții de mai jos decid dacă sudo este implicat deloc.
Condiția 1: proprietarul acceptat poate face asta fără sudo
Pe majoritatea desktopurilor Linux, managerul de rețea deține deja conexiunile VPN, iar autorizarea lui trece prin polkit, nu prin sudo. Un utilizator căruia i se permite să ridice o conexiune o poate face din linia de comandă fără nicio regulă root. Verificați ce permite managerul înainte de a presupune că butonul are nevoie de privilegiu. Dacă răspunsul este da, modificarea din sudoers rezolvă o problemă care nu există.
nmcli connection show
nmcli connection up "Work VPN"
Dacă managerul refuză, citiți de ce: o regulă polkit lipsă, o conexiune deținută de alt utilizator sau un profil stocat unde utilizatorul nu îl poate citi. Fiecare dintre acestea are o corectare acceptată, mai îngustă decât o regulă sudo. Escaladarea privilegiilor este ultima soluție, nu prima.
Condiția 2: regula numește un singur executabil și argumentele sale
Dacă sudo este cu adevărat necesar, regula ar trebui să numească comanda exactă și, unde este posibil, argumentele pe care le poate folosi. O regulă care lasă un utilizator să ruleze un script wrapper este doar atât de sigură cât permisiunile acelui script, pentru că utilizatorul poate edita ce va executa root. O regulă cu un metacaracter după comandă este aceeași problemă într-o formă mai scurtă.
sudo -l -U alice
ls -l /usr/local/sbin/vpn-up
Verificați fiecare cale din lanțul comenzii: binarul, scriptul pe care îl apelează, fișierul de configurare pe care îl citește și orice director dintre ele. Dacă utilizatorul poate scrie în oricare dintre ele, regula restrânsă este în practică root nelimitat. Și argumentele contează, pentru că o comandă care acceptă o cale de configurare poate fi îndreptată spre un fișier controlat de utilizator. Scrieți regula pentru operațiune, nu pentru buton.
Opriți-vă dacă comanda are nevoie de un fișier controlat de utilizator pentru a funcționa. Atunci designul este greșit, și nicio sintaxă sudoers nu îl va face sigur.
Condiția 3: întreaga politică este analizată, nu doar linia dumneavoastră
Validați cu editorul care blochează fișierul și verifică sintaxa, și validați politica asamblată, nu un fragment. Un fișier care se analizează singur poate totuși rupe ordinea de includere sau poate duplica o regulă astfel încât comportamentul să se schimbe.manualul visudo documentează atât editorul care blochează, cât și modul doar de verificare folosit aici.
sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher
Verificarea raportează fișierul și linia când eșuează, iar acel raport este partea utilă. Reparați modificarea dorită prin editor în loc să forțați salvarea unei erori cunoscute, pentru că o politică stricată poate bloca toți administratorii deodată. Fișierele din directorul de includere au nevoie și de proprietatea și modul cerute de manual, altfel vor fi ignorate sau respinse. Sintaxa este doar prima poartă: după ce trece, citiți din nou regula și întrebați ce permite de fapt.
Opriți-vă dacă singurul mod de a face modificarea să funcționeze este să dezactivați verificarea sintaxei. Aceasta nu este o politică, este o pană care așteaptă o repornire.
Recuperare: păstrați o sesiune care încă funcționează
Înainte de a salva, asigurați-vă că o sesiune administrativă autorizată este deja deschisă și că există o a doua cale în mașină. O greșeală în sudoers vă poate lua capacitatea de a o repara, iar un buton pe desktop nu merită acest risc. Dacă sudo este deja stricat, folosiți calea de recuperare documentată a sistemului, nu improvizați una.
sudo -n true
id
Alternative precum pkexec depind de propria instalare și politică, așa că nu sunt o a doua cerere root garantată. Țineți autorizarea locală separată și de furnizarea secretului VPN: o regulă sudo nu poate debloca un agent de secrete absent și nu satisface MFA-ul gateway-ului. După corectare, testați contul normal executând doar operațiunea dorită, apoi folosiți controalele obișnuite ale managerului.
Decizia se încheie când puteți spune ce condiție a justificat sudo, ce numește regula, că întreaga politică este analizată și cum ați recupera dacă nu. Un lansator privilegiat care vă costă accesul administrativ este o afacere proastă și de obicei poate fi evitat.