PrivateTmp: hook-ul a scris fișierul, dar unde a ajuns?

Hook-urile raportează succes, iar aceeași cale pare încă goală dintr-un shell. Ambele afirmații pot fi adevărate în același timp, pentru că un serviciu systemd poate trăi în propriul spațiu de nume de montare cu un director temporar privat. Odată înțeles acest lucru, întrebarea interesantă devine dacă scrierea a reușit deloc.

Două directoare temporare, o singură cale

Setarea de izolare oferă unității o vedere privată asupra directoarelor temporare, în loc să le facă doar pentru citire. Procesele din afara unității nu pot vedea ce scrie acolo, iar tot ce lasă în urmă este aruncat când unitatea se oprește. Așa că o cale afișată de hook și o cale verificată dintr-un shell pot indica obiecte diferite cu același nume.

Aceasta este o problemă de vizibilitate și arată ca o problemă de pierdere a datelor. Nimic nu a fost șters, pentru că fișierul se află pur și simplu într-un spațiu de nume din care shell-ul nu face parte. Aceași comandă se comportă diferit când este rulată în interiorul unității, și aceasta este observația care de obicei rezolvă disputa. Citește setările unității înainte de a trage vreo concluzie despre scriere.

Separă invizibilul de ceea ce nu poate fi scris

O scriere reușită și o deschidere eșuată produc dovezi diferite, iar această distincție decide reparația. Dacă hook-ul spune că fișierul a fost creat, dar un cititor extern nu îl găsește, ai o întrebare despre spațiul de nume. Dacă hook-ul raportează o eroare de permisiune sau o deschidere eșuată, fișierul nu a fost niciodată scris și nicio schimbare a spațiului de nume nu va ajuta.

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

Calea prin rădăcina procesului arată vederea proprie a serviciului asupra sistemului de fișiere, supusă verificărilor de permisiuni asupra acelui proces cât timp rulează încă. Citește jurnalul unității în aceeași sesiune, pentru că o eroare de scriere și un fișier lipsă se confundă ușor după ce cineva a decis deja cauza.

Dă datelor partajate o locație explicită

Datele de care are nevoie doar serviciul aparțin directorului său temporar privat. Datele pe care trebuie să le citească un alt proces au nevoie de o cale definită pentru ambele, cu proprietar, mod și expirare declarate. Decide care dintre cele două cazuri îl ai înainte de a edita unitatea. Majoritatea acestor incidente provin din tratarea unui fișier privat ca fiind partajat.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

Un director de execuție plasează dosarul sub zona de execuție a sistemului, îl creează pentru utilizatorul și grupul configurate ale unității și îl elimină când unitatea se oprește. Adaugă-l printr-un drop-in pentru ca unitatea pachetului să rămână intactă, apoi reîncarcă managerul și repornește acea instanță, acceptând că clienții ei se vor reconecta.

Păstrează orice director de execuție pe care unitatea instalată îl cere deja. Înlocuirea listei în loc de adăugarea la ea este o modalitate obișnuită de a strica o funcție nelegată pe care nimeni nu o asociază cu schimbarea.

Două straturi de privilegii pot să nu fie de acord

Managerul de servicii creează directorul pentru utilizatorul configurat al unității, în timp ce demonul VPN poate coborî separat în propriul cont înainte de a rula un hook de conexiune. Sunt straturi diferite și pot numi identități diferite.

Un director deținut de root cu un mod restrictiv este perfect vizibil pentru un demon care a renunțat deja la privilegii și totuși nu poate scrie în el. Eroarea este citită atunci ca o problemă de permisiuni, deși calea există exact acolo unde te așteptai. Compară proprietarul directorului cu identitatea raportată de hook. Când diferă, modul nu a fost niciodată întrebarea.

Verifică identitatea sub care rulează de fapt hook-ul înainte de a schimba proprietatea. Schimbarea utilizatorului de execuție al serviciului pentru a repara un director poate modifica accesul la dispozitive și privilegiile de rețea în altă parte, ceea ce este un preț mare pentru o problemă mică.

Verifică întreaga predare

Confirmă patru lucruri deodată: hook-ul scrie sub identitatea sa reală, cititorul prevăzut poate consuma fișierul, utilizatorii nelegați nu pot, iar oprirea unității curăță conform proiectului. Apariția unui fișier în directorul temporar partajat al gazdei nu este o cerință și este de obicei un semn că schimbul nu a primit niciodată propria cale. Testează cititorul după o repornire, nu doar în timpul primei rulări. Comportamentul de curățare face parte din proiect, așa că observă-l în loc să îl presupui.

Starea persistentă aparține unui loc cu o durată de viață potrivită, deoarece un director de execuție este menit să dispară. Alege locația după durata de viață, nu după comoditate. Acest obicei previne următoarea versiune a aceleiași investigații.