eBPF LSM este modul în care atașezi programe eBPF la hook-urile Linux Security Module, adică exact în punctele unde kernelul ia decizii de securitate. Documentația oficială a kernelului spune clar că aceste programe permit instrumentarea în timp real a hook-urilor LSM pentru politici MAC și audit. Tradus practic: poți adăuga controale suplimentare peste mecanismele deja existente din Linux, fără să scrii un modul kernel clasic și fără să recompili kernelul pentru fiecare ajustare de politică.
Asta face eBPF LSM interesant mai ales pentru profesioniștii care lucrează în securitate Linux, platform engineering sau DevSecOps. Dacă ai deja AppArmor, SELinux sau alte controale, eBPF LSM poate juca rolul unui strat suplimentar foarte țintit: de exemplu, să urmărească anumite operațiuni sensibile asupra fișierelor, memoriei sau proceselor și să decidă fie blocarea lor, fie doar emiterea de evenimente pentru investigație. Nu este o soluție „magic bullet” și nu înlocuiește designul de securitate de bază, dar este util atunci când vrei politici mai fine sau observabilitate mai bună asupra deciziilor de securitate.
Pentru publicul tehnic, diferența importantă este între enforcement și observare. Un program eBPF LSM poate returna o eroare, cum ar fi -EPERM, pentru a opri o acțiune care încalcă politica definită. Kernelul oferă chiar un exemplu de acest tip. Dar aceeași infrastructură poate fi folosită și defensiv, în mod mai puțin intruziv, pentru a scrie informații către un buffer de evenimente și a construi un flux de audit. În practică, asta înseamnă că înainte să blochezi ceva în producție, poți rula o perioadă în mod de observare, ca să vezi ce s-ar fi încălcat și unde ai riscul de false positive.
Exact aici apare valoarea pentru carieră. eBPF LSM nu este doar un subiect de kernel hacking, ci o competență aplicată: învățarea modului în care politicile de securitate pot fi observate, testate gradual și apoi întărite. Pentru cine vrea roluri în hardening Linux, cloud security sau detection engineering, e util să înțeleagă că securitatea modernă nu înseamnă doar „deny by default”, ci și telemetrie bună, corelare și validare înainte de blocare.
Există însă câteva condiții reale. Documentația kernelului pentru LSM BPF se bazează pe BTF, iar BTF este descris oficial ca formatul de metadate care codifică informația de tip pentru programele și map-urile BPF. Cu BTF disponibil, programele pot folosi tipuri din kernel mai sigur și mai portabil, iar un scenariu comun este generarea fișierului vmlinux.h din /sys/kernel/btf/vmlinux. Dacă mediul de build nu corespunde cu mediul unde faci deploy, compatibilitatea devine o problemă reală, nu un detaliu de laborator.
La fel de importantă este partea de privilegii. Documentația capabilities(7) arată că Linux are CAP_BPF din versiunea 5.8 pentru operațiuni BPF privilegiate. Asta contează organizațional: nu orice utilizator ar trebui să poată încărca sau atașa politici eBPF LSM. În plus, încărcarea programelor se face prin syscall-ul bpf(), iar pentru atașare documentația kernelului menționează fie BPF_RAW_TRACEPOINT_OPEN, fie, mai simplu, helperul libbpf bpf_program__attach_lsm. Cu alte cuvinte, pe lângă idee, ai nevoie de un lanț tehnic coerent: kernel compatibil, BTF disponibil, toolchain și control strict al privilegiilor.
Ca observație operațională, merită verificat și ce LSM-uri sunt active pe sistem. Kernelul expune lista prin /sys/kernel/security/lsm, iar ordinea de acolo reflectă ordinea verificărilor. Pentru o echipă de securitate, asta este important fiindcă eBPF LSM trebuie evaluat în contextul politicilor deja existente, nu izolat.
Concluzia realistă este că eBPF LSM merită folosit atunci când ai nevoie de politici suplimentare și de observabilitate mai fină asupra încălcărilor, dar numai cu disciplină: întâi observare, apoi validare, apoi enforcement gradual. Pentru carieră, înțelegerea acestei abordări arată maturitate tehnică: nu doar cum „blochezi”, ci cum introduci controale noi pe Linux fără să destabilizezi sistemele pe care încerci să le protejezi.
