Drept de căutare pe fiecare director înainte de cheie

Modul 0600 și proprietarul corect nu garantează că serviciul poate deschide o cheie. Permisiunea lipsă se află de obicei pe un director de deasupra. Linux rezolvă o cale componentă cu componentă, iar fiecare pas are nevoie de drept de căutare înainte de a fi încercat următorul. Citiți întreaga cale, nu ultima linie a listării.

Dreptul de citire este ultimul pas, nu singurul

Deschiderea unui fișier cere kernelului să parcurgă de la rădăcină sau de la directorul de lucru fiecare componentă a căii. Un director fără drept de căutare oprește acea parcurgere cu o eroare de permisiune. Modul fișierului însuși nu este niciodată consultat, așa că o cheie perfect lizibilă pare ilizibilă. Eroarea apare adesea la deschidere fără a numi directorul, de aceea este învinuit fișierul final.

Pentru un director, bitul de execuție înseamnă căutare, nu executarea conținutului. O cheie rămâne date, iar nicio parte a acestei reparații nu cere marcarea ei ca executabilă.

Parcurgeți calea ca și contul serviciului

Listați fiecare componentă împreună cu proprietarul și modul ei, apoi repetați citirea ca identitatea reală a serviciului. Diferența dintre shell-ul dumneavoastră și daemon este adesea întregul răspuns. Urmați legăturile simbolice până la ținta reală, pentru că este verificată calea rezolvată.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

Un serviciu poate deschide fișiere și în mai multe faze. O parte din material este citită în timpul configurării privilegiate, în timp ce alte fișiere sunt deschise după renunțarea la privilegii. Un shell root care citește fișierul nu reproduce accesul lucrătorului ulterior. Un spațiu de nume de montare poate prezenta o altă vedere a aceleiași căi, mai ales într-un container, așa că comparați vederea sistemului de fișiere a daemonului cu a dumneavoastră.

Schimbați cea mai îngustă permisiune care se potrivește

Alegeți cea mai mică aranjare care dă acces procesului: un grup controlat cu drept de căutare pe directoarele necesare, o locație gestionată pe care serviciul o deține deja, sau alt mecanism documentat. Citirea unui fișier nu cere drept de scriere pe directorul lui. O permisiune largă de scriere de grup pe configurație privilegiată nu este o reparație normală a traversării. Nici 0777 recursiv nu este o soluție.

Notați ce componentă ați schimbat și de ce. O schimbare de permisiune fără un motiv consemnat este greu de verificat și ușor de uitat.

Priviți dincolo de moduri doar după parcurgere

Dacă biții de mod par suficienți, verificările rămase sunt ACL-urile, politica de securitate și restricțiile sandbox. Un ACL poate acorda acces pe care biții de mod îl sugerează absent, sau poate refuza acces pe care par să îl permită. Acele setări aparțin proprietarului actual al configurației și trebuie ajustate îngust în loc să fie dezactivate. O diferență de rădăcină sau de director de lucru poate explica și o cale absolută care funcționează într-un context și eșuează în altul.

Nu pierdeți din vedere ce este fișierul în timp ce reparați accesul. Un certificat CA este public prin proiectare; o cheie privată nu este. Fișierele pe care clientul le rescrie au nevoie și de drepturi de scriere diferite de cele ale unei chei de identitate doar pentru citire. Inspectați metadatele fără a tipări secrete, apoi confirmați că serviciul însuși funcționează după schimbare. O notă scurtă în documentația serviciului scutește următoarea persoană de aceeași parcurgere.