Varnost SELinuxa: Nadzorujte svoj sistem Linux do milimetra natančno

Informatec Digital » Viri » Varnost SELinuxa: Nadzorujte svoj sistem Linux do milimetra natančno

SELinux se morda sliši kot tehnologija, rezervirana za navdušence nad jedrom, vendar je v resnici eno najmočnejših varnostnih orodij, ki so danes na voljo v Linuxu . Če upravljate strežnike, varnost Dockerjevih vsebnikov , oblačno infrastrukturo ali celo nekoliko občutljive namizne računalnike, razumevanje delovanja SELinuxa bistveno vpliva na to, ali je sistem preprosto »dobro konfiguriran«, ali pa je težko ogroziti sistem, tudi z ranljivostmi ničelnega dne.

Kljub slovesu "zapletenosti" SELinux ponuja zelo logičen model: določa, kaj lahko vsak proces počne in s katerimi objekti lahko komunicira, in če karkoli odstopa od tega skripta, ga jedro takoj ustavi . Namesto da bi slepo zaupali, da se bo root obnašal pravilno ali da vaši demoni ne bodo imeli napak, SELinux uveljavlja obvezen nadzor dostopa, ki velja celo za superuporabnika, z uporabo zelo podrobnih oznak in pravilnikov.

Kaj je SELinux in katere težave rešuje?

Varnostno izboljšan Linux (SELinux) je varnostni modul jedra Linuxa, ki temelji na LSM (Linux Security Modules). Prvotno ga je razvila NSA v sodelovanju z Red Hatom in drugimi partnerji, od različice jedra 2.6 pa je uradni del jedra. Ni ločena aplikacija, temveč razširitev jedra, ki dodaja sistem obveznega nadzora dostopa (MAC) in nadzor dostopa na podlagi vlog (RBAC).

Za razliko od klasičnega diskrecijskega nadzora dostopa (DAC) v Unixu – dovoljenja lastnika, skupine, drugih in rwx – v SELinuxu odločitve o dostopu ne temeljijo na izbiri lastnika datoteke, temveč na globalni politiki, ki jo določi varnostni skrbnik. DAC je še vedno prisoten in ima prednost: če DAC zavrne, SELinux ne posreduje; četudi DAC dovoli, lahko SELinux še vedno blokira operacijo v skladu s svojo politiko.

Arhitektura SELinux jasno ločuje komponente: na eni strani kodo jedra, ki sprejema varnostne odločitve , na drugi strani pa module pravilnikov, ki določajo, kaj je dovoljeno in kaj ne. Ta ločitev omogoča prilagajanje pravil brez ponovnega prevajanja jedra in poenostavlja število komponent, ki lahko vplivajo na varnost sistema.

SELinux je bil privzeto sprejet v distribucijah, kot so Fedora, Red Hat Enterprise Linux, CentOS in Scientific Linux, globoko pa je integriran tudi v sisteme, kot je Android, kjer se uporablja za omejevanje sistemskih procesov in aplikacij na zelo specifične domene. V svetu BSD in GNU/Linux obstajajo alternative, kot so AppArmor, TOMOYO in TrustedBSD (na macOS/FreeBSD), vendar SELinux izstopa po stopnji granularnosti, ki jo ponuja za vse sistemske objekte.

Od DAC do MAC: zakaj klasični model ni več dovolj

V tradicionalnem sistemu Unix se model domena-objekt upravlja z uporabo DAC: vsaka datoteka ali vir ima lastnika in dovoljenja, vsak proces, ki se izvaja pod imenom tega uporabnika, pa lahko s temi viri počne, kar hoče . To pomeni, da če se daemon izvaja pod imenom root, lahko vsaka izkoriščevalna napaka odpre vrata za nadzor polovice sistema s svojim korenskim kontekstom.

Tipični primeri vključujejo baze podatkov, katerih podatkovne datoteke bi morale biti upravljane le prek sistema za upravljanje podatkovnih zbirk (DBMS), vendar jih dejansko lahko berejo in spreminjajo procesi s korenskim UID-jem ; ali kritični demoni, ki se izvajajo s prekomernimi privilegiji. Programska napaka, prelivanje medpomnilnika ali slabo preverjanje vnosa lahko storitev spremenijo v oviro za celoten sistem.

SELinux doda plast obveznega nadzora dostopa (MAC) na vrh DAC. »Obvezno« pomeni, da skrbnik centralno določa nadzor dostopa s pravilniki in niti uporabniki niti procesi ne morejo sami omiliti teh pravil. Operacijski sistem uveljavlja te pravilnike tako, da pred odobritvijo oceni vsako ustrezno operacijo jedra.

Jedro s pomočjo LSM kavljev poizveduje SELinux ob vsakem občutljivem sistemskem klicu (odpiranje datotek, ustvarjanje vtičnic, priklop datotečnih sistemov, komunikacija prek IPC itd.). Na vsaki točki odločanja SELinux oceni operacijo na podlagi naložene politike in varnostnega konteksta subjekta in objekta . Če politika izrecno ne podeli dovoljenja, je dejanje zavrnjeno, ne glede na to, ali ima proces root dostop ali ne.

Načini delovanja: vsiljujoči, permisivni in onemogočeni

SELinux lahko deluje v treh jasno ločenih operativnih stanjih, ki jih je pomembno razumeti, da se izognemo pretiravanju v produkciji:

• IzvrševanjeSELinux je omogočen in v celoti uveljavlja pravilnik. Vsa dejanja, ki jih pravila ne dovoljujejo, so blokirana in zabeležena.
• PermisivnoSELinux je aktiven, naloži pravilnik in označi datotečni sistem, vendar ne blokira Transakcije beleži le, kot da bi bile zavrnjene. To je idealno za odpravljanje napak in prilagajanje pravilnikov.
• onemogočenoSELinux je onemogočen. Ne uporabljajo se nobeni pravilniki in ne izvaja se označevanje. Sistem se zanaša na klasični model DAC.

Za hitre in začasne spremembe med uveljavljajočim in permisivnim načinom se uporablja ukaz `setenforce` , kjer je način določen kot 0 (permisivni) ali 1 (uveljavljajoči). Pomembno je vedeti, da je ta sprememba nestanovitna: po naslednjem ponovnem zagonu se bo način vrnil v način, ki je določen v konfiguraciji.

Če potrebujete trajno spremembo, morate urediti datoteko. /etc/selinux/config (ali /etc/sysconfig/selinux v nekaterih distribucijah) in prilagodite vrednost direktive SELINUX=disabled|permissive|enforcingSpremembe bodo uporabljene ob naslednjem zagonu in bodo v mnogih primerih vključevale ponovno označevanje datotečnega sistema.

Za preverjanje aktivnega načina lahko uporabite ukaze, kot sta getenforce ali sestatus . Prvi preprosto vrne Enforcing (Uveljavljanje), Permissive (Dovoljeno) ali Disabled (Onemogočeno); slednji ponuja popolnejši povzetek stanja SELinuxa, naloženih pravilnikov in aktivnih modulov.

Varnostni konteksti in sistem označevanja

Srce SELinuxa je njegov sistem varnostnih oznak ali kontekstov . Vsaka datoteka, proces, omrežna vrata, vtičnica, naprava itd. ima povezan kontekst, ki opisuje, kako se lahko uporablja. Ta kontekst je sestavljen iz več polj, ki skupaj tvorijo pogled SELinuxa na ta objekt.

Splošna oblika konteksta je user_u:role_r:type_t:level , z nekaj niansami, ki so odvisne od pravilnika (zlasti če se uporablja MLS/MCS). Vsako polje ima določen namen: uporabnika SELinuxa, vlogo, tip (imenovan tudi domena, ko se sklicujemo na procese) in raven ali kategorijo občutljivosti.

V praksi je najpomembnejši element tip (tretje polje), saj je velika večina pravilnikov oblikovanih kot razmerja med tipi . Na primer, omogočanje procesom tipa httpd_t dostop do datotek z oznako httpd_sys_content_t ali omogočanje določeni domeni komunikacijo z vtičnicami z oznako http_port_t.

Ti konteksti so shranjeni kot razširjeni atributi datotečnega sistemaZato je bistveno uporabljati datotečne sisteme, ki podpirajo xattrs (kot so ext4, XFS itd.). V primeru procesov so trenutni kontekst in drugi povezani konteksti izpostavljeni prek psevdodatotečnega sistema. /proc/<pid>/attr/ v datotekah, kot so current, exec, fscreate, prev, sockcreate ali keycreate.

Tipični primeri kontekstov v sistemu s ciljno usmerjeno politiko bi bili:

• system_u:object_r:httpd_sys_content_t:s0 za spletne vsebine, ki jih ponuja Apache ali Nginx.
• sistem_u:objekt_r:domači_uporabnik_t:s0 za domače imenike uporabnikov.
• system_u:system_r:httpd_t:s0 za izvedbeno domeno samega spletnega strežnika.

Razčlenitev komponent konteksta SELinux

Ko naletite na kontekst, kot je unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , se morda zdi kot hieroglifi, vendar vsak del ustreza določenemu konceptu znotraj SELinuxa in njegove referenčne politike.

El Uporabnik SELinuxa (po dogovoru s pripono) _uTo ni isto kot uporabnik Unix v /etc/passwd. SELinux vzdržuje svojo lastno uporabniško bazo podatkov in jih preslika na uporabnike Linuxa. Uporabnik SELinuxa lahko združi več uporabnikov Unixa, ker je ideja, da je plast MAC neodvisna od DAC.

El Vloga SELinux (s pripono _rTo določa, katere vloge lahko uporabnik ali domena prevzame. Če se uporablja strogo, se imenuje polni RBAC. Večina datotečnih objektov uporablja vlogo object_r, medtem ko se vloge, kot so system_r, user_r, staff_r ali sysadm_r, uporabljajo za procese glede na varnostni kontekst, ki ga morajo prevzeti.

El Tip ali domena SELinux (pripona _tV praksi je tip ključni element. Tip opisuje razred objekta ali izvajalno domeno procesa. Politika določa, katere interakcije so dovoljene med tipi: katere domene lahko berejo, pišejo, izvajajo ali komunicirajo s katerimi drugimi tipi objektov.

Ravni in kategorije se uporabljajo, kadar so omogočene politike večnivojske varnosti (MLS) ali večkategorijske varnosti (MCS). Občutljivosti so hierarhične (npr. s0, s1 itd.), kategorije pa ne (c0, c1, c2, ...). V zelo kritičnih okoljih – na primer v nekaterih vladnih organizacijah – se uporabljajo za zagotovitev, da se podatki lahko berejo in zapisujejo le navzdol na isto raven ali navzgor , ter za izolacijo podatkov glede na zelo specifične predelke.

Pravilniki SELinuxa: ciljno usmerjeni, strogi, MLS/MCS in modularnost

Varnost, ki jo uveljavlja SELinux, je določena z naloženo politiko . Politika je preprosto velik nabor pravil, ki opisujejo, katere domene lahko kaj počnejo na katerih tipih, kot tudi druge elemente (prehodi, pravila označevanja itd.). Distribucije običajno vključujejo standardne politike, tako da vam ni treba pisati vsega od začetka.

Najpogostejša politika se imenuje ciljno usmerjena . V tem načinu se znotraj omejenih domen izvajajo samo določeni procesi – predvsem omrežne storitve in visoko tvegani demoni, kot so Apache, Nginx, DNS, posredniki, SNMP, syslog itd. Vsi drugi uporabniški procesi se izvajajo v »neomejenih« domenah, kjer se v bistvu uporablja standardna varnost Linuxa, skupaj z beleženjem določenih dejanj.

Obstaja tudi stroga politika , pri kateri so praktično vsi procesi omejeni z določeno politiko. Je veliko varnejša, vendar jo je lahko tudi precej težje vzdrževati, če model ni dobro razumljen, saj lahko vsako neskladje v označevanju ali pravilih moti standardne poteke dela.

Za okolja z visoko stopnjo varnosti obstajajo pravilniki MLS/MCS (večstopenjska/večkategorijska varnost) , ki izkoriščajo občutljivosti in kategorije za uvedbo še natančnejših kontrol. Ti so značilni za zelo toga vojaška ali administrativna okolja in se zaradi visoke operativne kompleksnosti redko uporabljajo zunaj določenih kontekstov.

Sodobni pravilniki so distribuirani modularno . Namesto ene same monolitne datoteke pravilnikov se za specifične storitve uporabljajo ločeni moduli, kar močno poenostavi upravljanje in posodabljanje. Ti moduli se upravljajo z orodji, kot sta semodule in semanage module , ki omogočajo namestitev, odstranitev, omogočanje ali onemogočanje delov pravilnika, ne da bi morali vsakič znova prevajati celoten pravilnik.

Kako se SELinux odloča: subjekti, objekti, razredi in dovoljenja

Ko proces (subjekt) poskuša dostopati do vira (objekta), SELinux konceptualno postavi vprašanje: "Ali lahko domena tipa X izvede operacijo Y na objektu tipa Z, ki pripada razredu C?" . Odgovor se nato išče v pravilniku prek definiranih pravil.

V pravilnikih za uveljavljanje tipov (TE), ki jih uporablja večina distribucij in Android, vsak objekt pripada razredu ( datoteka, imenik, fifo_file, tcp_socket, proces itd.) in pravilnik določa, katera dovoljenja so možna za vsak razred: branje, pisanje, izvajanje, vezava, povezovanje, getattr, odpiranje in tako naprej.

Pravila TE so izražena zelo neposredno. Osnovni primer bi bil:

dovoli httpd_t http_port_t:tcp_socket ime_bind;

S tem pravilom politika določa, da lahko procesi v domeni httpd_t izvajajo operacijo name_bind na vtičnicah TCP z oznako http_port_t. Pristop se osredotoča na tipe in razrede objektov, ne na specifične poti , kar preprečuje presenečenja pri premikanju datotek ali spreminjanju struktur imenikov.

V sistemu Android se na primer atributi SELinux uporabljajo za združevanje tipov pod bolj splošnimi oznakami, kot je `appdomain` , tako da se lahko eno pravilo uporabi za več domen (`untrusted_app`, `isolated_app` itd.) brez ponavljanja definicij. Makri, kot je `rw_file_perms`, se uporabljajo tudi za združevanje več pogostih dovoljenj za datoteke in zmanjšanje napak, ki jih povzročijo spregledi.

Notranji statusi, AVC in register zavrnitev

Ko pride do zahteve za dostop, SELinux najprej preveri predpomnilnik dostopnih vektorjev (AVC) , predpomnilnik, ki shranjuje nedavne odločitve o dostopu, da se postopek pospeši. Če je odločitev že v predpomnilniku, se uporabi neposredno; v nasprotnem primeru se poizveduje požarni zid (notranji del SELinuxa v jedru), ki ovrednoti operacijo na podlagi pravilnika ter konteksta subjekta in objekta.

Če ni pravila, ki bi izrecno dovoljevalo zahtevano dejanje, je privzeta odločitev zavrnitev . Ta filozofija »privzete zavrnitve« je eden od stebrov SELinuxa in mu daje robustnost pred permisivno konfiguracijsko napako.

Ko v načinu uveljavljanja pride do zavrnitve, jedro zabeleži sporočilo tipa avc: zavrnjeno v sistemskih dnevnikih. Odvisno od distribucije se lahko prikaže v /var/log/audit/audit.logv /var/log/messages ali pa jih zajame demon auditd. Ta sporočila vključujejo kontekst procesa (scontext), kontekst objekta (tcontext), razred, zahtevano operacijo in druge podatke, ki so zelo uporabni za odpravljanje napak.

V permisivnem načinu je operacija dovoljena, vendar se še vedno generira dogodek avc: denied , označen z permissive=1. To je čisti zlati rudnik za gradnjo in prilagajanje pravilnikov, saj vam omogoča, da vidite, kaj bi pokvarilo sistem, če bi se uveljavljanje izvedlo brez prekinitve normalnega delovanja.

Integracija SELinuxa v distribucije in Android

V ekosistemu strežnikov in namiznih računalnikov Linux je SELinux privzeto omogočen v Fedora, RHEL, CentOS in derivatiDebian in Ubuntu nudita polno podporo v svojih jedrih in paketih, čeprav je aktivacija običajno neobvezna in zahteva namestitev paketov, kot so selinux-basics, selinux-policy-default in auditd, čemur sledi globalno ponovno označevanje z fixfiles relabel.

Android je SELinux sprva vključil v različici 4.3 v permisivnem načinu, v delno uporabo je prešel v različici 4.4 (le za kritične domene, kot so installd, netd, vold in zygote), v celoti pa je integriran od različice Android 5.0 . Androidova politika se osredotoča na izolacijo aplikacij, sistemskih storitev in občutljivih procesov z uporabo tipov in atributov, s ciljem zmanjšati vpliv morebitne kršitve katere koli od teh komponent.

Android uporablja koncepte, kot je tip untrusted_app za običajne procese aplikacij, atribute appdomain za združevanje domen aplikacij in kategorije MLS/MCS za izolacijo podatkov med aplikacijami in med fizičnimi uporabniki. Vse to skupaj preprečuje, da bi ogrožena aplikacija ušla iz svojega peskovnika, tudi če pridobi zelo široka uporabniška dovoljenja.

Pomembno: Android poenostavlja model SELinux tako, da ignorira uporabnike, vloge in napredne občutljivosti. Obstaja samo en uporabnik SELinux (u), dve osnovni vlogi (r za subjekte in object_r za objekte), občutljivost pa je vedno s0. Kategorije so tiste, ki naredijo razliko za izolacijo podatkov.

Primerjava z AppArmorjem in drugimi LSM-ji

V mnogih razpravah se neizogibno pojavi primerjava med SELinuxom in AppArmorjem , saj sta oba varnostna modula za Linux in ponujata MAC-e. Vendar pa sta njuna pristopa precej različna in to je vredno razumeti, preden izberete enega ali drugega za svoje okolje.

SELinux definira pravilnik, osredotočen na objekte in njihove tipe: vsakemu objektu v sistemu (datoteke, procesi, vtičnice, vrata, naprave, IPC-ji itd.) je dodeljena oznaka. Odločitve o dostopu se sprejemajo na podlagi kontekstov subjekta in objekta, ne glede na natančno pot datoteke. Zaradi tega je sistem bolj stabilen glede na spremembe strukture imenikov ali alternativne poglede datotečnega sistema (chroot, vsebniki, povezovalne povezave itd.).

AppArmor pa uporablja pravilnik, osredotočen na naloge in poti. Za vsak program definira profile, pri čemer določa, do katerih poti datotek, vrat itd. lahko dostopa in s kakšnimi dovoljenji. Konfiguracija je bolj intuitivna in na splošno uporabniku prijaznejša za skrbnike, ki ne želijo postati strokovnjaki za SELinux, vendar je njegov nadzor nekoliko manj natančen in bolj odvisen od strukture datotečnega sistema.

Oba imata skupno načelo privzete zavrnitve, vendar ga uporabljata različno: AppArmor privzeto zavrne le naloge, ki jih pokriva s profili, medtem ko SELinux v strogem načinu to možnost razširi na celoten sistem in vse označene objekte. Posledično SELinux običajno ponuja globljo raven omejitve , vendar za ceno obsežnejše in kompleksnejše politike.

Praktična orodja za upravljanje SELinuxa

Delo s SELinuxom se opira na vrsto orodij ukazne vrstice, ki poenostavljajo upravljanje načinov, označevanja, logičnih vrednosti in modulov pravilnikov. Čeprav se to na prvi pogled morda zdi preobremenjujoč arzenal, nekaj pripomočkov pokriva večino vsakodnevnih opravil.

Za ogled varnostnega konteksta datotek in procesov lahko uporabite možnost -Z v pogostih ukazih, kot so ls, ps ali id. Na primer, ls -Z Poleg dovoljenj DAC bo prikazal tudi kontekst SELinuxa vsake datoteke, kar vam bo omogočilo hitro preverjanje, ali je označevanje pričakovano.

Ukaz `chcon` ("spremeni kontekst") vam omogoča ročno spreminjanje celotnega konteksta datoteke ali le določenih delov (vloga, tip, obseg) z uporabo možnosti, kot so `-r`, `-to` in `-l`. Uporaben je za enkratne popravke, vendar je pomembno vedeti, da se lahko vaše spremembe izgubijo, če se označevanje ponovno uporabi v skladu s pravilnikom z orodji, kot sta `restorecon` ali `fixfiles`.

Orodje semanage je švicarski nož upravljanja pravilnikov izvajalnega okolja. Z različnimi podukazi lahko upravljate trajne kontekste datotek (fcontext), preslikave prijav med uporabniki Linuxa in SELinuxa (login), uporabnike SELinuxa in njihove vloge (user), označena vrata (port), logične vrednosti in celo module pravilnikov. Vse to brez potrebe po ponovnem prevajanju celotnega pravilnika iz izvorne kode.

Za preverjanje in spreminjanje stanja logičnih vrednosti – majhnih stikal, ki omogočajo ali onemogočajo bloke pravil znotraj pravilnika – se poleg same logične vrednosti setsebool uporabljata tudi getsebool in setsebool . Tipična logična vrednost je httpd_enable_homedirs, ki ob aktivnosti omogoča spletnemu strežniku dostop do domačih imenikov uporabnikov (uporabno za ~user/public_html/).

Končno, ukazi, kot je fixfiles, omogočajo, da vsilite popolno preimenovanje datotečnega sistema v skladu z določenimi pravili, semodule pa poskrbi za namestitev, seznam, omogočanje ali onemogočanje modulov pravilnikov (.pp), ki jih pakira in distribuira referenčni pravilnik ali skrbnik.

Ustvarjanje in prilagajanje pravilnikov po meri

Ko aplikacija nima lastnega modula SELinux ali potrebujete bolj specifično omejitev, je čas, da se lotite dela in ustvarite pravilnike po meri . Morda se sliši zapleteno, vendar je potek dela precej dobro opredeljen, če natančno sledite določenim korakom.

Prvi korak je zagotoviti, da so ustrezni objekti (izvršljive datoteke, podatkovni imeniki, vtičnice itd.) označeni z ustreznimi tipi. To je mogoče doseči z definiranjem pravil konteksta datotek z ukazom ` semanage fcontext` in njihovo uporabo z ukazom `restorecon`, pri čemer se z uporabo regularnih izrazov zajamejo celotna drevesa imenikov.

Sistem se nato običajno preklopi v permisivni način za ta računalnik (ali v nekaterih primerih za določeno domeno) in aplikaciji je dovoljeno normalno delovanje, medtem ko SELinux beleži vse stavke `avc: denied` , ki bi se lahko pojavili. Ti dnevniki, običajno analizirani z orodji, kot je audit2allow , se uporabljajo za pridobivanje kandidatov za pravila.

Referenčne politike so običajno strukturirane v treh datotekah na aplikacijo: datoteka .te, ki vsebuje pravila TE (allow, type, domain_type itd.), datoteka .fc, ki vsebuje pravila konteksta datoteke, in datoteka .if, ki vsebuje javne vmesnike, ki jih lahko drugi moduli ponovno uporabijo. Vse to se z uporabo ukaza make prevede v module .pp in naloži s ukazom semodule.

Ključnega pomena je, da ne zaupate slepo vsemu, kar predlaga audit2allow: ponavadi je bolj permisiven, kot je nujno potrebno . V idealnem primeru bi morali ročno pregledati predlagana pravila, po potrebi ustvariti nove tipe, da ločite občutljive podatke od nepomembnih, in kadar zavrnjena operacija ni kritična, razmisliti o uporabi pravil dontaudit, da ustavite snemanje šuma brez odobritve dovoljenj.

V okoljih, kot sta SUSE Linux Micro ali Android, so na voljo dodatna orodja (na primer Udica za ustvarjanje pravilnikov vsebnikov iz opisov JSON), ki avtomatizirajo del postopka s hitrim prilagajanjem pravilnika določenim vsebnikom, ne da bi se bilo treba naučiti celotnega jezika pravilnikov od začetka.

Zaradi celotnega ekosistema kontekstov, modularnih pravilnikov, logičnih vrednosti in orodij za upravljanje je SELinux izjemno robustna in prilagodljiva varnostna platforma . Z nekaj začetnih naložb v učenje omogoča zelo natančno omejevanje delovanja posamezne storitve ali aplikacije, s čimer drastično okrepi površino sistema za napade pred izkoriščanjem, zlonamerno programsko opremo in človeškimi napakami.