De ce mutarea unui certificat VPN îi rupe eticheta SELinux

Certificatele pot sta în directorul corect cu un mod lizibil și proprietate root, iar serviciul poate raporta în continuare că nu poate deschide fișierul. Pe un sistem SELinux, acea combinație indică un mecanism anume, nu permisiunile. Eticheta a călătorit cu fișierul, pentru că o redenumire nu creează un obiect nou. Inode-ul a păstrat contextul de securitate pe care îl avea pe calea veche, iar politica pentru calea nouă nu a primit niciodată șansa de a-l atribui pe al ei.

Ce face de fapt o redenumire unei etichete

Un fișier își poartă contextul SELinux ca date de atribut atașate inode-ului. Redenumirea în interiorul unui singur sistem de fișiere schimbă intrarea de director și nimic altceva, ceea ce este rapid și atomic, și este motivul pentru care contextul supraviețuiește mutării. Nicio politică nu este întrebată, nicio valoare implicită nu este aplicată și niciun avertisment nu este tipărit.

Copierea se comportă altfel. O copie creează un inode nou în directorul destinație, iar politica atribuie un context după tipul acelui director, așa că un certificat copiat ajunge de obicei cu eticheta corectă, în timp ce unul mutat rămâne greșit. Această singură diferență explică cea mai mare parte a confuziei din această clasă de tichete.

Mutările între sisteme de fișiere revin la semantica de copiere, așa că aceeași comandă se poate comporta diferit pe două mașini în funcție de faptul dacă /etc se află pe un volum propriu. Verificați asta înainte de a concluziona că instrumentul nu este de încredere. O privire la tabelul de montare vă spune ce tip de mutare ați făcut.

Citiți eticheta actuală față de cea așteptată

Trei comenzi doar de citire răspund la întrebare fără a schimba nimic. Prima arată ce are fișierul acum, a doua raportează ce așteaptă politica pentru exact acea cale, iar a treia listează fiecare fișier din director a cărui etichetă diferă.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Rularea uscată este cea în care trebuie să aveți încredere, pentru că numește fiecare fișier al cărui context se abate de la politică și tot lasă sistemul neatins. Dacă certificatul apare în acea listă, ați găsit discrepanța dintre ce înseamnă calea și ce susține fișierul. Dacă nu apare, eticheta este deja ce vrea politica, iar timpul dumneavoastră aparține altundeva.

Apoi corelați diferența cu un refuz real. O nepotrivire este dovada unei etichete greșite, nu dovada că serviciul a eșuat din cauza ei, iar o corecție aplicată fără un refuz corespunzător în jurnal este o presupunere cu pași în plus.

Restabiliți maparea în loc să inventați o excepție

Pentru o locație standard politica deja mapează calea, așa că restorecon o aplică și treaba este gata. Țineți domeniul la directorul pe care îl reparați; reetichetarea întregului sistem de fișiere este lentă, perturbatoare și îngroapă greșeala originală sub o schimbare foarte mare.

Pentru un director personalizat ordinea contează, iar inversarea ei produce o comandă care raportează succes fără să schimbe nimic. Maparea aparține politicii, reetichetarea aparține finalului, iar rularea uscată aparține înaintea ambelor. Sărirea acelei ultime părți este felul în care o cale care nu a fost niciodată greșită ajunge totuși reetichetată.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon aplică o mapare; nu poate inventa una. Dacă nicio regulă nu descrie calea, nu există de unde restabili, de aceea maparea persistentă trebuie să existe înainte de reetichetare. Notați ce configurație deține acea mapare, pentru că altfel o mutare ulterioară, o actualizare de pachet sau o reetichetare recreează defectul și următoarea persoană pornește de la zero.

De ce chcon nu este soluția

chcon scrie un context direct pe fișier. Are efect imediat și este cea mai puțin durabilă opțiune disponibilă, pentru că o reetichetare a sistemului de fișiere reaplică politica și aruncă modificările manuale fără să întrebe. Fișierul pare reparat, iar reparația are o dată de expirare pe care nimeni nu a scris-o. Ce doriți în schimb este o regulă care descrie calea, astfel încât fiecare fișier care ajunge acolo să primească automat același tratament.

Mai rău, învață lecția greșită: maparea de bază lipsește în continuare, așa că defectul revine săptămâni mai târziu fără un declanșator evident și fără memoria ocolirii. Folosiți chcon doar ca experiment temporar pentru a confirma o ipoteză, apoi înlocuiți-l cu o mapare care supraviețuiește următoarei reetichetări și verificați că înlocuitorul este într-adevăr la locul lui.

Când eticheta este corectă și accesul tot eșuează

Începeți cu directoarele părinte. Permisiunea de traversare este verificată pe fiecare componentă a căii, așa că un certificat etichetat corect într-un director în care serviciul nu poate intra rămâne ilizibil. Atât SELinux, cât și permisiunea obișnuită trebuie să permită fiecare pas, iar repararea uneia nu o repară pe cealaltă.

Apoi verificați identitatea procesului și sandbox-ul propriu al serviciului. O unitate cu un sandbox restrictiv poate refuza accesul la un fișier pe care politica l-ar permite bucuroasă, iar din linia de jurnal cele două cauze arată identic. Confirmați care proces cere de fapt, nu care presupuneți că cere.

Rețineți că regulile dontaudit pot suprima mesajele de refuz, așa că un jurnal de audit gol este o dovadă slabă, nu o dovadă. Dacă politica pare corectă și accesul tot eșuează, investigați înainte de a genera un modul de permisiune larg, și nu dezactivați SELinux pentru a face simptomul să dispară. Ambele scurtături produc un sistem care pare să funcționeze și o postură de securitate pe care nimeni nu o poate descrie. O investigație scurtă este mai bună decât oricare dintre ele.