În administrarea Linux, multe investigații pornesc de la o întrebare simplă: cine a încercat să acceseze un fișier sensibil și când? fanotify este un API al kernelului Linux pentru notificarea și, în anumite scenarii, interceptarea evenimentelor de pe sistemul de fișiere. Documentația Linux îl descrie ca mecanism pentru „notification and interception of filesystem events”, cu utilizări precum scanarea antivirus sau managementul stocării ierarhice.
Pentru echipe defensive, fanotify nu este o soluție magică, ci un senzor util. Poate ajuta la observarea accesului la directoare critice, la declanșarea unor verificări înainte ca un fișier să fie deschis și la auditarea comportamentului aplicațiilor. Într-un program matur, el completează controale precum auditul utilizatorilor, grupurilor și accesului sudo, politici Mandatory Access Control și backupuri testate.
Cum funcționează, pe scurt
Fluxul de bază are două etape. Aplicația defensivă apelează `fanotify_init`, care creează un grup fanotify și întoarce un file descriptor asociat cozii de evenimente. Apoi folosește `fanotify_mark` pentru a adăuga, modifica sau elimina marcaje pe obiecte ale sistemului de fișiere. În funcție de flaguri și de suportul kernelului, marcajele pot viza fișiere, directoare, mount-uri sau filesystem-uri.
Când apare un eveniment, descriptorul fanotify devine citibil și poate fi urmărit cu mecanisme standard precum `poll`, `select` sau `epoll`. Asta îl face potrivit pentru servicii de monitorizare care rulează în userspace și reacționează la evenimente fără să interogheze continuu discul.
Important: fanotify nu înseamnă doar „logare”. API-ul poate produce evenimente informative, de tip notificare, dar și evenimente de permisiune. Pentru `FAN_ACCESS_PERM`, o aplicație vrea să citească un fișier sau director; pentru `FAN_OPEN_PERM`, o aplicație vrea să deschidă un fișier sau director. În aceste cazuri, procesul care ascultă trebuie să trimită un răspuns către descriptorul fanotify, permițând sau refuzând accesul. În practică, astfel de decizii trebuie proiectate conservator, testate și limitate la scenarii clare, ca să nu blocheze servicii legitime.
Unde ajută în audit defensiv
Un caz realist este monitorizarea accesului la zone sensibile: directoare cu chei de aplicație, fișiere de configurare, artefacte de build sau zone montate pentru date critice. fanotify poate oferi semnale despre încercări de deschidere sau citire, iar serviciul de monitorizare poate corela evenimentul cu identitatea procesului, ora, calea urmărită și politica internă.
În containere și medii cu straturi de filesystem, trebuie înțeles contextul. OverlayFS poate schimba modul în care apar fișierele între straturi, așa că merită citit și ghidul despre OverlayFS, copy-up și whiteouts înainte să presupui că un eveniment reflectă simplu „fișierul original”.
fanotify este util și în arhitecturi în care un serviciu userspace face verificări înainte de acces, de exemplu validări de integritate sau scanări defensive. Conceptual, seamănă cu alte mecanisme moderne care mută o decizie în userspace, dar cu riscuri diferite. Dacă lucrezi cu politici de acces, compară rolul lui cu profilurile AppArmor personalizate: AppArmor restricționează capabilități și căi conform politicii, fanotify observă și poate cere decizii pe evenimente de filesystem.
Verificare și operare sigură
Pentru debugging și audit, `/proc//fdinfo/` poate afișa informații despre descriptorii fanotify și marcajele asociate. Documentația kernelului arată câmpuri precum `fanotify flags`, `event-flags`, `mnt_id`, `mflags`, `mask` și `ignored_mask`, în format hexazecimal. Asta ajută la verificarea faptului că serviciul urmărește exact ce crezi că urmărește.
Operațional, începe cu monitorizare pasivă înainte de evenimente de permisiune. Măsoară volumul de evenimente, latența, impactul asupra aplicațiilor și cazurile false pozitive. Setează politici simple, păstrează loguri utile și documentează clar ce se întâmplă dacă serviciul fanotify se oprește. Pentru decizii userspace sensibile, tratează problemele de timp și stare cu aceeași atenție ca în mecanisme precum Seccomp User Notifications: nu lua decizii pe presupuneri fragile.
Limite importante
fanotify nu înlocuiește auditd, AppArmor, SELinux, EDR-ul, hardeningul sau backupul. Nu este o arhivă completă a tuturor acțiunilor utilizatorilor și nu repară singur configurații greșite. Este un mecanism de semnalizare și, în anumite clase, de decizie asupra accesului la filesystem.
Folosit corect, adaugă vizibilitate și control într-o zonă critică: accesul la fișiere. Folosit fără testare, poate produce zgomot, blocaje sau o falsă senzație de siguranță.
Întrebări frecvente
fanotify este același lucru cu auditd?
Nu. fanotify monitorizează evenimente de filesystem și poate lucra cu evenimente de permisiune, dar auditd rămâne un mecanism dedicat de audit la nivel de sistem.
Poate fanotify să blocheze accesul la fișiere?
Da, pentru evenimente de permisiune precum `FAN_OPEN_PERM` și `FAN_ACCESS_PERM`, aplicația userspace poate răspunde cu allow sau deny. Articolul recomandă folosirea conservatoare și testată.
Cum verific dacă un proces are marcaje fanotify?
Poți inspecta `/proc//fdinfo/`, unde kernelul poate afișa informații despre descriptorul fanotify și marcajele asociate.
Înlocuiește fanotify AppArmor sau SELinux?
Nu. fanotify este complementar; AppArmor și SELinux aplică politici de control al accesului, iar fanotify oferă notificări și, în anumite cazuri, decizii pe evenimente de filesystem.
