Linux Server Hardening – Deo 5: SELinux i AppArmor – mandatorna kontrola pristupa

Sve što je ova serija do sada pokrila — SSH, firewall, ažuriranja, audit — bavi se time ko sme da uđe u sistem i šta se beleži kad uđe. Ovaj deo se bavi drugačijim, dopunskim pitanjem: čak i kad neko (ili neka aplikacija) legitimno radi na serveru, šta tačno sme da radi na nivou samog operativnog sistema. SELinux i AppArmor su dva alata koja odgovaraju na to pitanje, i budući da izazivaju dosta zabune oko toga šta tačno rade i zašto se razlikuju od običnih Unix dozvola, ovaj tekst uzima malo više vremena da objasni mehanizam pre nego što pređe na praktične preporuke.

Standardne Unix dozvole i zašto nisu dovoljne

Svako ko je radio sa Linux-om zna za standardne dozvole fajlova — vlasnik, grupa, ostali, sa pravima čitanja, pisanja i izvršavanja (read/write/execute). Ovo se u bezbednosnoj terminologiji naziva DAC — Discretionary Access Control (diskrecioni kontrola pristupa). "Diskrecioni" ovde znači da vlasnik resursa sam odlučuje ko sme šta sa njim da radi, i da root korisnik po definiciji zaobilazi sva ta ograničenja — root sme sve, na svakom fajlu, bez izuzetka.

Ovo je tačno mesto gde DAC pokazuje svoju granicu: ako napadač uspe da kompromituje proces koji radi kao root (na primer, kroz ranjivost u veb serveru koji iz nekog razloga radi sa root privilegijama), taj napadač efektivno dobija neograničen pristup celom sistemu. Standardne dozvole fajlova tu više ne pomažu — kompromitovani root proces sme sve što i sam root nalog sme.

Šta je MAC i zašto menja pravila igre

MAC — Mandatory Access Control (obavezna kontrola pristupa) — je drugačiji model, gde ograničenja ne postavlja vlasnik fajla, već centralna, sistemska politika koju ni root ne može jednostavno zaobići. I SELinux i AppArmor su MAC implementacije: oba postavljaju dodatni sloj pravila iznad standardnih Unix dozvola, sloj koji ograničava šta sme da radi čak i proces koji tehnički radi sa root privilegijama.

Konkretan primer razjašnjava razliku: ako veb server (koji radi kao root ili sa povišenim pravima zbog vezivanja na port 80) bude kompromitovan kroz ranjivost u aplikaciji, standardne Unix dozvole ne sprečavaju napadača da pristupi, recimo, /etc/shadow fajlu sa lozinkama — proces ima root privilegije, pa mu je to tehnički dozvoljeno. MAC politika, međutim, može eksplicitno da kaže "ovaj konkretan proces, čak i sa root privilegijama, sme da pristupa samo ovim tačno određenim fajlovima i portovima" — i tu granicu ni root ne može da pređe bez izmene same MAC politike, što je odvojen, dodatno zaštićen korak.

SELinux — pristup preko oznaka (labela)

SELinux (Security-Enhanced Linux), razvijen prvobitno od strane NSA, radi tako što svakom objektu u sistemu — svakom fajlu, procesu, portu, mrežnoj utičnici — dodeljuje bezbednosnu oznaku (label), zapisanu u formatu koji izgleda kao "korisnik:uloga:tip:nivo". Politika SELinux-a zatim definiše koji tip sme da komunicira sa kojim drugim tipom — na primer, "proces sa oznakom tipa httpd_t sme da čita fajlove sa oznakom tipa httpd_sys_content_t, ali ne i fajlove sa oznakom tipa shadow_t".

Ključna posledica ovog dizajna: bezbednost ne zavisi od toga gde se fajl fizički nalazi u sistemu fajlova, već isključivo od njegove oznake. Ako se fajl premesti ili kopira, njegova oznaka putuje sa njim (ili se ponovo dodeljuje na osnovu pravila za tu lokaciju) — sistem ne "zaboravlja" svoja ograničenja samo zato što je fajl promenio putanju.

AppArmor — pristup preko putanja

AppArmor radi na jednostavnijem principu: umesto oznaka na svakom objektu, definiše profile po aplikaciji, gde svaki profil kaže "ovaj konkretan program (identifikovan svojom putanjom, npr. /usr/sbin/apache2) sme da pristupa tačno ovim fajl putanjama i ima tačno ove mogućnosti (capabilities)". Profili se čuvaju kao čitljivi tekstualni fajlovi u /etc/apparmor.d/, što ih čini znatno lakšim za ručno pisanje i razumevanje u odnosu na SELinux politiku.

Slabost ovog pristupa proizlazi direktno iz njegove jednostavnosti: pošto se pravila vezuju za putanju fajla, a ne za sam fajl kao objekat, teoretski je moguće zaobići ograničenje kroz hard link ili bind mount koji istom fajlu daje drugu putanju koja nije pokrivena profilom. U praksi ovo je redak, sofisticiran scenario, ali predstavlja fundamentalnu razliku u dizajnu u odnosu na SELinux-ov pristup baziran na oznakama koje prate sam objekat.

Koji distribucija koristi šta

Izbor između ova dva alata je u praksi retko slobodan izbor — određen je distribucijom. RHEL i njegovi derivati (Rocky Linux, AlmaLinux, Fedora, CentOS Stream) dolaze sa SELinux-om uključenim po difoltu. Debian i Ubuntu dolaze sa AppArmor-om uključenim po difoltu. Iako je tehnički moguće instalirati "onaj drugi" alat na bilo kojoj od ovih distribucija, to zahteva dodatan rad i gubi prednost dobre podrške i testiranja koju donosi podrazumevani izbor te distribucije.

Šta treba uraditi

• Ne boriti se protiv podrazumevanog izbora distribucije bez konkretnog, jakog razloga — SELinux na RHEL familiji i AppArmor na Debian/Ubuntu familiji su bolje testirani i podržani izbori upravo zato što su podrazumevani za tu distribuciju
• Nikad trajno ne isključivati SELinux ili AppArmor kao "brzo rešenje" kad neka aplikacija prijavi grešku pristupa — ovo je najčešća, a najštetnija greška u praksi, jer trajno uklanja ceo sloj zaštite umesto da se reši konkretan, uzak problem
• Za SELinux, koristiti "targeted" politiku (podrazumevana na većini distribucija) za standardne servere — ona ograničava rizičnije servise (veb server, baza podataka) dok ostatak sistema ostavlja nesputan, što je razuman kompromis između bezbednosti i operativne jednostavnosti

Enforcing/permissive i enforce/complain — isti koncept, različita imena

Oba alata imaju analogan par radnih režima, samo pod različitim imenima. SELinux poznaje tri stanja: enforcing (politika se aktivno primenjuje — zabranjene radnje se blokiraju i beleže), permissive (politika se ne primenjuje, ali se sve što bi bilo zabranjeno beleži u log, kao da se "vežba" bez stvarne posledice), i disabled (SELinux potpuno isključen). AppArmor ima ekvivalentan par po profilu: enforce (blokira i beleži) i complain (samo beleži, bez blokiranja) — AppArmor nema odvojeno "disabled" stanje na nivou celog sistema u istom smislu, jer se ovo kontroliše po profilu.

Ova dva "meka" režima — permissive kod SELinux-a i complain kod AppArmor-a — nisu bezbednosne mere same po sebi; to su alati za bezbedno testiranje. Omogućavaju administratoru da vidi šta bi politika blokirala, bez stvarnog rizika da nešto prestane da radi, pre nego što se politika stvarno uključi.

Šta treba uraditi

• Nikad ne pretpostaviti da je sistem zaštićen samo zato što je SELinux ili AppArmor instaliran — proveriti stvarno stanje (`getenforce` za SELinux, `aa-status` za AppArmor) i potvrditi da je politika u enforcing/enforce režimu, ne samo prisutna na disku
• Za novu aplikaciju ili prilagođen profil, uvek početi u permissive/complain režimu, pustiti aplikaciju da radi kroz normalan, realan obrazac korišćenja neko vreme, pregledati šta bi bilo blokirano, prilagoditi politiku, i tek onda preći na enforcing/enforce
• Za AppArmor, koristiti pomoćne alate poput aa-genprof (generiše početni profil posmatranjem ponašanja aplikacije) i aa-logprof (analizira zabeležene "complain" događaje i predlaže dopune profila) — ovo znatno ubrzava iterativan proces izgradnje ispravnog profila
• Kad sistem ili aplikacija prijavi grešku pristupa koja izgleda kao lažno pozitivan rezultat (legitimna operacija je blokirana), rešenje je dopuna ili izmena konkretnog pravila politike, ne gašenje čitavog MAC sistema

Napomena o riziku: permissive/complain režim ne pruža stvarnu zaštitu — samo beleži šta bi bilo blokirano. Sistem koji je "privremeno" prebačen u permissive radi rešavanja jednog problema, a nikad vraćen u enforcing, deluje zaštićeno na prvi pogled (SELinux je "instaliran"), a u stvarnosti ne blokira ništa. Ovo je čest, tih način da hardening napravljen ranije u ovoj seriji izgubi deo svoje vrednosti bez ičije svesne odluke — uvesti periodičnu proveru stvarnog radnog režima kao deo redovne bezbednosne revizije, ne oslanjati se na to da će "ostati onako kako je jednom postavljeno".

Kontejneri — mesto gde MAC dobija dodatnu ulogu

Za okruženja koja koriste kontejnere (Docker, Podman), SELinux i AppArmor dobijaju dodatnu, značajnu ulogu: ograničavanje šta kontejner sme da radi na nivou hosta, čak i ako je aplikacija unutar kontejnera kompromitovana. Standardna izolacija kontejnera oslanja se na kernel mehanizme (namespaces, cgroups) koji sami po sebi nisu nepробojni — MAC politika dodaje dodatan sloj koji ograničava štetu ako ta izolacija ipak bude probijena.

Šta treba uraditi

• Za Docker/Podman okruženja na SELinux sistemima, koristiti podrazumevanu SELinux integraciju (oznake kontejnera) umesto pokretanja kontejnera sa --privileged ili sličnim opcijama koje zaobilaze ograničenja radi "lakšeg rešavanja problema"
• Imati u vidu razliku pomenutu ranije u tekstu — SELinux-ova podrška za MLS/MCS (Multi-Level/Multi-Category Security) omogućava izolaciju kontejnera jedne od druge, ne samo od hosta, dok AppArmor tu mogućnost nativno nema u istoj meri
• Za okruženja gde je izolacija kontejnera jedne od druge (ne samo od hosta) bitan zahtev, ovo razmotriti kao jedan od faktora pri odabiru platforme, ne samo kao sporednu tehničku pojedinost

Ovim se proširuje Linux Server hardening serija na temu mandatorne kontrole pristupa — sloj zaštite koji, za razliku od svega prethodno pokrivenog u seriji, ostaje aktivan čak i ako napadač uspe da dobije root privilegije, sve dok politika ostane u enforcing/enforce režimu i ostane pravilno održavana kroz vreme.