Dacă vrei să rulezi un proces riscant sau pur și simplu mai puțin de încredere pe un sistem Linux, primul impuls este adesea să folosești chroot și să consideri problema rezolvată. Numai că asta nu este suficient. Documentația oficială Linux spune clar că apelul chroot() schimbă doar o parte din rezolvarea căilor de fișiere și „nu este destinat” să ofere singur securitate completă. Cu alte cuvinte, un sandbox serios se construiește în straturi, nu dintr-o singură comandă.
Piesa de bază este izolarea prin namespaces. Manualul Linux explică faptul că un namespace învelește o resursă globală a sistemului astfel încât procesul din interior să o vadă ca pe propria lui instanță izolată. În practică, pentru un sandbox contează mai ales user namespace, mount namespace, PID namespace și, când este cazul, network namespace. User namespace ajută la limitarea privilegiilor vizibile în sandbox, mount namespace separă punctele de montare, PID namespace ascunde procesele gazdei, iar network namespace poate tăia complet accesul la rețea dacă nu ai nevoie de el.
Al doilea strat este filesystem-ul read-only. Aici mulți greșesc: dacă procesele din sandbox pot scrie liber în zone importante, izolarea devine mai fragilă și auditul mai dificil. Ideea corectă este să expui în sandbox doar ce trebuie și, pe cât posibil, în mod read-only. În loc să montezi direct sistemul gazdă, creezi o rădăcină minimală și legi doar directoarele strict necesare. Zonele care chiar trebuie să permită scriere, precum /tmp sau un director de lucru temporar, merită tratate separat, de preferat pe tmpfs sau într-un path dedicat, nu în tot root filesystem-ul.
Unde intră chroot în această schemă? Ca piesă suplimentară, nu ca fundație. Chroot poate ajuta la schimbarea perspectivei procesului asupra rădăcinii filesystem-ului, dar fără mount namespace, fără controlul montărilor și fără restricții de syscall rămâne incomplet. De aceea, în proiectele moderne, chroot este de obicei combinat cu alte mecanisme sau chiar înlocuit de unelte care orchestrează toate aceste straturi împreună.
Al treilea strat este seccomp. Kernelul Linux descrie seccomp filtering ca un mecanism prin care un proces poate defini filtre pentru syscall-urile primite. Pe scurt, chiar dacă aplicația ajunge să ruleze, nu va putea apela orice syscall dorește. Aici este una dintre cele mai importante idei pentru administratori: un sandbox bun nu se bazează doar pe „unde vede fișierele”, ci și pe „ce are voie să ceară kernelului”. Într-un scenariu defensiv, regula sănătoasă este o allowlist minimă: permiți doar ce trebuie pentru aplicația ta și blochezi restul.
O abordare practică și mai sigură decât construcția manuală de la zero este bubblewrap. Proiectul este folosit tocmai pentru a compune sandbox-uri din namespaces, montări controlate, root temporar și filtre suplimentare. Documentația lui explică foarte clar două lucruri utile: creează un nou mount namespace gol, iar părțile din filesystem pe care le expui pot fi montate readonly. Tot acolo este subliniat și un adevăr important: bubblewrap nu este o politică de securitate gata făcută; nivelul real de protecție depinde de argumentele și deciziile tale.
Pentru un sandbox defensiv, modelul sănătos arată așa: root minimal, directoare esențiale montate readonly, /tmp separat, fără acces la rețea dacă nu este obligatoriu, fără expunerea socket-urilor sensibile de pe gazdă și cu un profil seccomp cât mai îngust. Dacă bagi în sandbox prea mult din sistemul real, de exemplu socket-uri D-Bus, directoare de sesiune sau zone scriibile din gazdă, atunci slăbești exact bariera pe care încercai să o construiești.
Mai există o capcană importantă: testele funcționale nu sunt suficiente. Faptul că aplicația pornește într-un sandbox nu înseamnă că sandbox-ul este bine configurat. Verifică separat ce procese vede, dacă are rețea, ce directoare sunt montate readonly și dacă filtrele seccomp chiar se aplică. Într-un laborator sau într-o mașină virtuală poți începe cu un profil strict și lărgi treptat doar ce se dovedește necesar.
Pe scurt, dacă vrei un sandbox Linux solid, gândește în straturi. Namespaces oferă separarea, chroot schimbă perspectiva asupra rădăcinii, filesystem-ul read-only reduce suprafața de scriere, iar seccomp taie din capabilitățile la nivel de syscall. Niciuna dintre aceste piese nu este magică de una singură. Împreună, însă, pot transforma o simplă izolare de confort într-un control real al riscului.
