SELinux sigurnost: Kontrolirajte svoj Linux sustav do milimetra

Informatec Digital » Sredstva » SELinux sigurnost: Kontrolirajte svoj Linux sustav do milimetra

SELinux možda zvuči kao tehnologija rezervirana za kernel geekove, ali zapravo je jedan od najmoćnijih sigurnosnih alata dostupnih u Linuxu danas . Ako upravljate poslužiteljima, sigurnošću Docker kontejnera , cloud infrastrukturom ili čak malo osjetljivim stolnim računalima, razumijevanje načina na koji SELinux funkcionira čini veliku razliku između sustava koji je jednostavno "dobro konfiguriran" i onog koji je teško kompromitirati, čak i s zero-day ranjivostima.

Unatoč svojoj reputaciji "kompliciranog" sustava, SELinux nudi vrlo logičan model: definira što svaki proces može raditi i s kojim objektima može komunicirati, a ako nešto odstupa od tog scenarija, kernel ga odmah zaustavlja . Umjesto slijepog povjerenja da će se root ponašati ispravno ili da vaši daemoni neće imati greške, SELinux provodi obaveznu kontrolu pristupa koja se primjenjuje čak i na superkorisnika, koristeći vrlo detaljne oznake i pravila.

Što je SELinux i koje probleme rješava?

Sigurnosno poboljšani Linux (SELinux) je sigurnosni modul Linux kernela temeljen na LSM-u (Linux Security Modules). Izvorno ga je razvila NSA u suradnji s Red Hatom i drugim partnerima, a od verzije kernela 2.6 službeni je dio kernela. Nije zasebna aplikacija, već proširenje kernela koje dodaje obvezni sustav kontrole pristupa (MAC) i kontrolu pristupa temeljenu na ulogama (RBAC).

Za razliku od klasične Unix diskrecijske kontrole pristupa (DAC) - vlasnik , grupa, ostali i rwx dozvole - u SELinuxu, odluke o pristupu ne temelje se na izboru vlasnika datoteke, već na globalnoj politici koju je uspostavio sigurnosni administrator. DAC je i dalje prisutan i ima prednost: ako DAC odbije, SELinux ne intervenira; ali čak i ako DAC dopusti, SELinux i dalje može blokirati operaciju prema svojoj politici.

SELinux arhitektura jasno odvaja komponente: s jedne strane, kernel kod koji donosi sigurnosne odluke , a s druge strane, module pravila koji definiraju što je dopušteno, a što nije. Ovo odvajanje omogućuje prilagođavanje pravila bez ponovnog kompajliranja kernela i pojednostavljuje broj komponenti koje mogu utjecati na sigurnost sustava.

SELinux je standardno usvojen u distribucijama kao što su Fedora, Red Hat Enterprise Linux, CentOS i Scientific Linux, a također je duboko integriran u sustave poput Androida, gdje se koristi za ograničavanje sistemskih procesa i aplikacija na vrlo specifične domene. U svijetu BSD-a i GNU/Linuxa postoje alternative kao što su AppArmor, TOMOYO i TrustedBSD (na macOS/FreeBSD-u), ali SELinux se ističe po razini granularnosti koju nudi nad svim sistemskim objektima.

Od DAC-a do MAC-a: zašto klasični model više nije dovoljan

U tradicionalnom Unix sustavu, model domene i objekta upravlja se pomoću DAC-a: svaka datoteka ili resurs ima vlasnika i dozvole, a svaki proces koji se pokreće kao taj korisnik može s tim resursima raditi što god želi . To znači da ako se daemon pokreće kao root, svaka iskorištena greška može otvoriti vrata kontroli polovice sustava s njegovim root kontekstom.

Tipični primjeri uključuju baze podataka čije se podatkovne datoteke trebaju manipulirati samo putem DBMS-a, ali koje procesi s korijenskim UID-om zapravo mogu čitati i mijenjati ; ili kritični demoni koji se izvode s prekomjernim privilegijama. Programska pogreška, prelijevanje međuspremnika ili loša validacija unosa mogu pretvoriti uslugu u autocestu za cijeli sustav.

SELinux dodaje sloj Obavezne kontrole pristupa (MAC) na vrh DAC-a. "Obavezno" znači da administrator centralno definira kontrolu pristupa putem pravila i da ni korisnici ni procesi ne mogu sami ublažiti ta pravila. Operativni sustav provodi ta pravila procjenjujući svaku relevantnu operaciju jezgre prije nego što je dopusti.

Jezgra, koristeći LSM hooks, upituje SELinux o svakom osjetljivom sistemskom pozivu (otvaranje datoteka, stvaranje utičnica, montiranje datotečnih sustava, komunikacija putem IPC-a itd.). U svakoj točki odluke, SELinux procjenjuje operaciju na temelju učitane politike i sigurnosnog konteksta subjekta i objekta . Ako politika izričito ne daje dopuštenje, radnja se odbija, bez obzira je li proces root ili ne.

Načini rada: prisilni, dopuštajući i onemogućeni

SELinux može raditi u tri jasno diferencirana operativna stanja, koja je važno razumjeti kako bi se izbjeglo pretjerano korištenje u produkciji:

• izvršenjeSELinux je omogućen i u potpunosti provodi pravila. Sve radnje koje nisu dopuštene pravilima su blokirane i zabilježene.
• PermisivnoSELinux je aktivan, učitava pravila i označava datotečni sustav, ali ne blokira Bilježi transakcije samo kao da su odbijene. To je idealno za otklanjanje pogrešaka i prilagođavanje pravila.
• onesposobljenSELinux je onemogućen. Ne primjenjuju se nikakve politike niti se vrši označavanje. Sustav se oslanja na klasični DAC model.

Za brze i privremene promjene između načina izvršavanja i dopuštanja, koristi se naredba `setenforce` , gdje je način određen kao 0 (dopuštajući) ili 1 (provedbeni). Važno je znati da je ova promjena promjenjiva: nakon sljedećeg ponovnog pokretanja, način rada će se vratiti na onaj definiran u konfiguraciji.

Ako vam je potrebna trajna promjena, morate urediti datoteku. /etc/selinux/config (ili /etc/sysconfig/selinux u nekim distribucijama) i prilagodite vrijednost direktive SELINUX=disabled|permissive|enforcingPromjene će se primijeniti pri sljedećem pokretanju i, u mnogim slučajevima, uključivat će ponovno označavanje datotečnog sustava.

Za provjeru aktivnog načina rada možete koristiti naredbe poput getenforce ili sestatus . Prva jednostavno vraća Enforcing, Permissive ili Disabled; druga pruža potpuniji sažetak statusa SELinuxa, učitanih pravila i aktivnih modula.

Sigurnosni konteksti i sustav označavanja

Srce SELinuxa je njegov sustav sigurnosnih oznaka ili konteksta . Svaka datoteka, proces, mrežni port, utičnica, uređaj itd. ima pridruženi kontekst koji opisuje kako se može koristiti. Taj kontekst sastoji se od nekoliko polja koja zajedno tvore SELinuxov pogled na taj objekt.

Opći format konteksta je user_u:role_r:type_t:level , s nekim nijansama ovisno o politici (osobito ako se koristi MLS/MCS). Svako polje ima određenu svrhu: SELinux korisnika, ulogu, tip (također se naziva domena kada se odnosi na procese) i razinu ili kategoriju osjetljivosti.

U praksi, najvažniji element je tip (treće polje), budući da je velika većina pravila politike formulirana kao odnosi između tipova . Na primjer, dopuštanje procesima tipa httpd_t pristupa datotekama označenima s httpd_sys_content_t ili dopuštanje određenoj domeni komunikacije sa socketima označenima s http_port_t.

Ovi konteksti se pohranjuju kao prošireni atributi datotečnog sustavaStoga je bitno koristiti datotečne sustave koji podržavaju xattr-ove (kao što su ext4, XFS itd.). U slučaju procesa, trenutni kontekst i drugi povezani konteksti izloženi su putem pseudo-datotečnog sustava. /proc/<pid>/attr/ u datotekama kao što su current, exec, fscreate, prev, sockcreate ili keycreate.

Tipični primjeri konteksta u sustavu s ciljanom politikom bili bi:

• system_u:object_r:httpd_sys_content_t:s0 za web sadržaj koji poslužuje Apache ili Nginx.
• system_u:object_r:home_user_t:s0 za korisničke početne direktorije.
• system_u:system_r:httpd_t:s0 za domenu izvršenja samog web poslužitelja.

Raščlamba komponenti SELinux konteksta

Kada naiđete na kontekst poput unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , može se činiti kao hijeroglifi, ali svaki dio odgovara specifičnom konceptu unutar SELinuxa i njegove referentne politike.

El Korisnik SELinuxa (po dogovoru s sufiksom) _uOvo nije isto što i Unix korisnik u /etc/passwd. SELinux održava vlastitu bazu podataka korisnika i mapira ih na Linux korisnike. SELinux korisnik može grupirati nekoliko Unix korisnika, jer je ideja da MAC sloj bude neovisan o DAC-u.

El SELinux uloga (sa sufiksom _rOvo definira koje uloge korisnik ili domena mogu preuzeti. Ako se koristi strogo, naziva se puni RBAC. Većina objekata datoteka koristi ulogu object_r, dok se uloge poput system_r, user_r, staff_r ili sysadm_r primjenjuju na procese ovisno o sigurnosnom kontekstu koji moraju preuzeti.

El Vrsta ili domena SELinuxa (sufiks _tU praksi, tip je ključni element. Tip opisuje klasu objekta ili domenu izvršenja procesa. Politika određuje koje su interakcije dopuštene između tipova: koje domene mogu čitati, pisati, izvršavati ili komunicirati s kojim drugim vrstama objekata.

Razine i kategorije koriste se kada su omogućene politike višerazinske sigurnosti (MLS) ili višekategorijske sigurnosti (MCS). Osjetljivosti su hijerarhijske (npr. s0, s1 itd.), dok kategorije nisu (c0, c1, c2, ...). U vrlo kritičnim okruženjima - na primjer, određene vladine organizacije - koriste se kako bi se osiguralo da se podaci mogu čitati samo prema dolje i pisati na istu razinu ili prema gore te kako bi se podaci izolirali prema vrlo specifičnim odjeljcima.

SELinux pravila: ciljana, stroga, MLS/MCS i modularnost

Sigurnost koju provodi SELinux određena je učitanim pravilima . Pravila su jednostavno veliki skup pravila koja opisuju koje domene mogu što raditi na kojim tipovima, kao i druge elemente (prijelaze, pravila označavanja itd.). Distribucije obično pakiraju standardna pravila tako da ne morate sve pisati od nule.

Najčešća politika naziva se ciljana . U ovom načinu rada, samo određeni procesi - uglavnom mrežne usluge i visokorizični daemoni poput Apachea, Nginxa, DNS-a, proxyja, SNMP-a, sysloga itd. - izvode se unutar ograničenih domena. Svi ostali korisnički procesi izvode se u "neograničenim" domenama, gdje se u biti primjenjuje standardna Linux sigurnost, uz zapisivanje određenih radnji.

Postoji i stroga politika , u kojoj su gotovo svi procesi ograničeni određenom politikom. Mnogo je sigurnija, ali može biti i znatno teža za održavanje ako model nije dobro shvaćen, jer svaka razlika u označavanju ili pravilima može poremetiti standardne tijekove rada.

Za okruženja s visokom sigurnošću postoje MLS/MCS (Multi-Level/Multi-Category Security) politike koje iskorištavaju osjetljivosti i kategorije kako bi nametnule još finije kontrole. One su tipične za vrlo kruta vojna ili administrativna okruženja i rijetko se koriste izvan specifičnih konteksta zbog svoje visoke operativne složenosti.

Moderne politike distribuiraju se modularno . Umjesto jedne monolitne datoteke politike, za određene usluge koriste se zasebni moduli, što uvelike pojednostavljuje upravljanje i ažuriranja. Tim se modulima upravlja alatima poput semodule i semanage module , koji vam omogućuju instaliranje, uklanjanje, omogućavanje ili onemogućavanje dijelova politike bez ponovnog kompiliranja cijele politike svaki put.

Kako SELinux odlučuje: subjekti, objekti, klase i dozvole

Kada proces (subjekt) pokuša pristupiti resursu (objektu), SELinux konceptualno postavlja pitanje: "Može li domena tipa X izvršiti operaciju Y na objektu tipa Z koji pripada klasi C?" . Odgovor se zatim traži u politici putem definiranih pravila.

U pravilima za provedbu tipova (TE), koja koristi većina distribucija i Android, svaki objekt pripada klasi ( datoteka, direktorij, fifo_datoteka, tcp_socket, proces itd.) i pravilo definira koja su dopuštenja moguća za svaku klasu: čitanje, pisanje, izvršavanje, povezivanje, povezivanje, getattr, otvaranje i tako dalje.

TE pravila su izražena vrlo izravno. Osnovni primjer bio bi:

dopusti httpd_t http_port_t:tcp_socket name_bind;

Ovim pravilom, politika označava da procesi u domeni httpd_t mogu izvršavati operaciju name_bind na TCP utičnicama označenim s http_port_t. Pristup se fokusira na tipove i klase objekata, a ne na specifične putanje , što sprječava iznenađenja prilikom premještanja datoteka ili promjene strukture direktorija.

U Androidu, na primjer, SELinux atributi se koriste za grupiranje tipova pod općenitijim oznakama poput `appdomain` , tako da se jedno pravilo može primijeniti na više domena (`untrusted_app`, `isolated_app` itd.) bez ponavljanja definicija. Makroi poput `rw_file_perms` također se koriste za grupiranje nekoliko uobičajenih dozvola za datoteke i smanjenje pogrešaka uzrokovanih propustima.

Interni statusi, AVC i registar odbijenica

Kada se pojavi zahtjev za pristup, SELinux prvo konzultira Access Vector Cache (AVC) , predmemoriju koja pohranjuje nedavne odluke o pristupu kako bi se ubrzao proces. Ako je odluka već u predmemoriji, koristi se izravno; u suprotnom se upituje vatrozid (unutarnji dio SELinuxa u jezgri), koji procjenjuje operaciju na temelju pravila te konteksta subjekta i objekta.

Ako ne postoji pravilo koje izričito dopušta traženu radnju, zadana odluka je odbiti . Ova filozofija "odbijanja po zadanim postavkama" jedan je od stupova SELinuxa i ono što mu daje otpornost na dopuštajuće pogreške konfiguracije.

Kada se dogodi odbijanje u načinu prinudnog izvršavanja, kernel zapisuje poruku tipa avc: odbijeno u sistemskim zapisnicima. Ovisno o distribuciji, može se pojaviti u /var/log/audit/audit.logNa /var/log/messages ili ih može uhvatiti daemon auditd. Ove poruke uključuju kontekst procesa (scontext), kontekst objekta (tcontext), klasu, traženu operaciju i druge podatke vrlo korisne za otklanjanje pogrešaka.

U permisivnom načinu rada, operacija je dopuštena, ali se i dalje generira događaj avc: denied , označen s permissive=1. Ovo je čisto zlato za izgradnju i prilagođavanje politika, jer vam omogućuje da vidite što bi narušilo sustav ako bi se provođenje pravila implementiralo bez prekidanja normalnog rada.

Integracija SELinuxa u distribucije i Android

U ekosustavu Linux servera i stolnih računala, SELinux je omogućen prema zadanim postavkama u Fedora, RHEL, CentOS i derivatiDebian i Ubuntu pružaju punu podršku u svojim kernelima i paketima, iako je aktivacija obično opcionalna i zahtijeva instaliranje paketa kao što su selinux-basics, selinux-policy-default i auditd, nakon čega slijedi globalno ponovno označavanje s fixfiles relabel.

Android je u početku uključio SELinux u verziji 4.3 u permisivnom načinu rada, prešao je na djelomičnu upotrebu u verziji 4.4 (samo za kritične domene kao što su installd, netd, vold i zygote), a potpuno je integriran od Androida 5.0 . Androidova politika usmjerena je na izoliranje aplikacija, sistemskih usluga i osjetljivih procesa pomoću tipova i atributa, s ciljem minimiziranja utjecaja kompromitiranja bilo koje od ovih komponenti.

Android koristi koncepte poput tipa untrusted_app za uobičajene procese aplikacija, atribute appdomain za grupiranje domena aplikacija i MLS/MCS kategorije za izolaciju podataka između aplikacija i između fizičkih korisnika. Sve to zajedno djeluje kako bi se spriječilo da kompromitovana aplikacija pobjegne iz svog sandboxa, čak i ako dobije vrlo široka korisnička dopuštenja.

Važno: Android pojednostavljuje SELinux model ignorirajući korisnike, uloge i napredne osjetljivosti. Postoji samo jedan SELinux korisnik (u), dvije osnovne uloge (r za subjekte i object_r za objekte), a osjetljivost je uvijek s0. Kategorije su ono što čini razliku za izolaciju podataka.

Usporedba s AppArmorom i drugim LSM-ovima

U mnogim raspravama neizbježno se javlja usporedba između SELinuxa i AppArmora , budući da su oba Linux sigurnosni moduli i nude MAC adrese. Međutim, njihovi pristupi su prilično različiti i vrijedi to razumjeti prije nego što odaberete jedan ili drugi za svoje okruženje.

SELinux definira politiku usmjerenu na objekte i njihove tipove: svakom objektu u sustavu (datoteke, procesi, utičnice, portovi, uređaji, IPC-ovi itd.) dodjeljuje se oznaka. Odluke o pristupu donose se na temelju konteksta subjekta i objekta, bez ovisnosti o točnoj putanji datoteke. To čini sustav stabilnijim u suočavanju s promjenama strukture direktorija ili alternativnim prikazima datotečnog sustava (chroot, spremnici, vezanje montiranja itd.).

AppArmor, s druge strane, primjenjuje politiku usmjerenu na zadatke i temeljenu na putanjama. Definira profile za svaki program, određujući kojim putanjama datoteka, portovima itd. može pristupiti i s kojim dozvolama. Intuitivniji je za konfiguriranje i općenito je jednostavniji za korištenje administratorima koji ne žele postati stručnjaci za SELinux, ali njegova kontrola je nešto manje granularna i više ovisi o strukturi datotečnog sustava.

Oba dijele princip uskraćivanja prema zadanim postavkama, ali ga primjenjuju drugačije: AppArmor prema zadanim postavkama uskraćuje samo zadatke koje pokriva profilima, dok SELinux, kada je u strogom načinu rada, proširuje ga na cijeli sustav i sve označene objekte. Kao rezultat toga, SELinux obično nudi dublju razinu ograničenja , nauštrb opsežnije i složenije politike.

Praktični alati za upravljanje SELinuxom

Rad sa SELinuxom oslanja se na niz alata naredbenog retka koji pojednostavljuju upravljanje načinima rada, označavanjem, logičkim vrijednostima i modulima pravila. Iako se na prvi pogled ovo može činiti kao preobilje, nekoliko uslužnih programa pokriva većinu svakodnevnih zadataka.

Za pregled sigurnosnog konteksta datoteka i procesa možete koristiti opciju -Z u uobičajenim naredbama poput ls, ps ili id. Na primjer, ls -Z Uz DAC dozvole, prikazat će i SELinux kontekst svake datoteke, što vam omogućuje brzu provjeru je li označavanje očekivano.

Naredba `chcon` ("promijeni kontekst") omogućuje vam ručnu izmjenu cijelog konteksta datoteke ili samo određenih dijelova (uloga, tip, raspon) pomoću opcija kao što su `-r`, `-to` i `-l`. Korisna je za jednokratne ispravke, ali važno je zapamtiti da se vaše promjene mogu izgubiti ako se označavanje ponovno primijeni prema pravilima pomoću alata poput `restorecon` ili `fixfiles`.

Alat semanage je švicarski nož za upravljanje pravilima za vrijeme izvođenja. Pomoću raznih podnaredbi možete upravljati trajnim kontekstima datoteka (fcontext), mapiranjem prijava između Linux i SELinux korisnika (login), SELinux korisnicima i njihovim ulogama (user), označenim portovima (port), logičkim vrijednostima, pa čak i modulima pravila. Sve to bez potrebe za ponovnim kompajliranjem cijelog pravila iz izvornog koda.

Za provjeru i promjenu stanja boolean vrijednosti - malih prekidača koji omogućuju ili onemogućuju blokove pravila unutar politike - koriste se getsebool i setsebool , uz samu setsebool boolean vrijednost . Tipična boolean vrijednost je httpd_enable_homedirs, koja, kada je aktivna, omogućuje web poslužitelju pristup kućnim direktorijima korisnika (korisno za ~user/public_html/).

Konačno, naredbe poput fixfiles omogućuju vam prisilno potpuno ponovno označavanje datotečnog sustava prema definiranim pravilima, a semodule se brine o instaliranju, popisivanju, omogućavanju ili onemogućavanju modula pravila (.pp) pakiranih i distribuiranih od strane referentne politike ili od strane administratora.

Izrada i prilagodba prilagođenih politika

Kada aplikacija nema vlastiti SELinux modul ili vam je potrebno specifičnije ograničenje, vrijeme je da se bacite na posao i stvorite prilagođene politike . Možda zvuči komplicirano, ali tijek rada je prilično dobro definiran ako pažljivo slijedite određene korake.

Prvi korak je osigurati da su relevantni objekti (izvršne datoteke, direktoriji podataka, utičnice itd.) označeni odgovarajućim tipovima. To se može postići definiranjem pravila konteksta datoteke s ` semanage fcontext` i njihovom primjenom s `restorecon`, korištenjem regularnih izraza za obuhvaćanje cijelih stabala direktorija.

Sustav se zatim obično stavlja u dopustivi način rada za to računalo (ili, u nekim slučajevima, za određenu domenu) i aplikaciji je dopušteno normalno pokretanje dok SELinux bilježi sve naredbe `avc: denied` koje bi se mogle dogoditi. Ovi zapisnici, obično analizirani alatima poput audit2allow , koriste se za izdvajanje kandidata za pravila.

Referentne politike obično su strukturirane u tri datoteke po aplikaciji: .te datoteka koja sadrži TE pravila (allow, type, domain_type itd.), .fc datoteka koja sadrži pravila konteksta datoteke i .if datoteka koja sadrži javna sučelja koja drugi moduli mogu ponovno koristiti. Sve se to kompilira u .pp module pomoću make i učitava semoduleom.

Ključno je ne vjerovati slijepo svemu što audit2allow predlaže: obično je popustljiviji nego što je strogo potrebno . Idealno bi bilo ručno pregledati predložena pravila, stvoriti nove tipove gdje je to prikladno kako biste odvojili osjetljive podatke od nebitnih podataka i, kada odbijena operacija nije kritična, razmisliti o korištenju dontaudit pravila za zaustavljanje snimanja šuma bez odobravanja dozvola.

U okruženjima kao što su SUSE Linux Micro ili Android, dostupni su dodatni alati (na primjer, Udica za generiranje politika kontejnera iz JSON opisa) koji automatiziraju dio procesa brzom prilagodbom politike određenim kontejnerima bez potrebe za učenjem cijelog jezika politika od nule.

Cijeli ovaj ekosustav konteksta, modularnih politika, logičkih vrijednosti i alata za upravljanje čini SELinux izuzetno robusnom i fleksibilnom sigurnosnom platformom . Uz početno ulaganje u učenje, omogućuje vrlo precizno ograničavanje onoga što svaka usluga ili aplikacija može učiniti, drastično ojačavajući površinu napada sustava protiv exploita, zlonamjernog softvera i ljudskih pogrešaka.