SELinux sigurnost: Kontrolirajte svoj Linux sistem do milimetra

Informatec Digital » Resursi » SELinux sigurnost: Kontrolirajte svoj Linux sistem do milimetra

SELinux možda zvuči kao tehnologija rezervirana za kernel entuzijaste, ali je zapravo jedan od najmoćnijih sigurnosnih alata dostupnih u Linuxu danas . Ako upravljate serverima, sigurnošću Docker kontejnera , cloud infrastrukturom ili čak malo osjetljivim desktop računarima, razumijevanje načina na koji SELinux funkcioniše čini svu razliku između sistema koji je jednostavno "dobro konfigurisan" i onog koji je teško kompromitovati, čak i sa zero-day ranjivostima.

Uprkos svojoj reputaciji "komplikovanog", SELinux nudi vrlo logičan model: definira šta svaki proces može raditi i s kojim objektima može komunicirati, a ako bilo šta odstupa od tog scenarija, kernel to odmah zaustavlja . Umjesto slijepog vjerovanja 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 politike.

Šta je SELinux i koje probleme rješava?

SELinux (SELinux) je sigurnosni modul Linux kernela zasnovan na LSM-u (Linux Security Modules). Izvorno ga je razvila NSA u saradnji 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 obavezni sistem kontrole pristupa (MAC) i kontrolu pristupa zasnovanu na ulogama (RBAC).

Za razliku od klasične Unix diskrecionarne kontrole pristupa (DAC) - dozvole vlasnika, grupe, drugih i rwx - u SELinuxu, odluke o pristupu se ne zasnivaju 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 interveniše; ali čak i ako DAC dozvoli, SELinux i dalje može blokirati operaciju u skladu sa svojom politikom.

SELinux arhitektura jasno razdvaja komponente: s jedne strane, kernel kod koji donosi sigurnosne odluke , a s druge strane, module pravila koji definiraju šta je dozvoljeno, a šta nije. Ovo razdvajanje omogućava prilagođavanje pravila bez ponovnog kompajliranja kernela i pojednostavljuje broj komponenti koje mogu utjecati na sigurnost sistema.

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 sisteme 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 nivou granularnosti koji nudi nad svim sistemskim objektima.

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

U tradicionalnom Unix sistemu, model domen-objekt se upravlja pomoću DAC-a: svaka datoteka ili resurs ima vlasnika i dozvole, i svaki proces koji se pokreće kao taj korisnik može raditi šta god želi s tim resursima . To znači da ako se daemon pokreće kao root, bilo koja iskorištena greška može otvoriti vrata kontroli polovine sistema pomoću njegovog root konteksta.

Tipični primjeri uključuju baze podataka čije bi se datoteke s podacima trebale manipulirati samo putem DBMS-a, ali koje procesi s korijenskim UID-om zapravo mogu čitati i mijenjati ; ili kritične demone koji se izvršavaju s prekomjernim privilegijama. Programska greška, prelijevanje bafera ili loša validacija unosa mogu pretvoriti servis u autoput za cijeli sistem.

SELinux dodaje sloj Obavezne kontrole pristupa (MAC) na vrh DAC-a. "Obavezno" znači da je kontrola pristupa centralno definirana od strane administratora putem politika i da ni korisnici ni procesi ne mogu sami ublažiti ova pravila. Operativni sistem provodi ove politike procjenjujući svaku relevantnu operaciju kernela prije nego što je dozvoli.

Jezgro, koristeći LSM hooks, šalje upite SELinuxu za svaki osjetljivi sistemski poziv (otvaranje datoteka, kreiranje socketa, montiranje datotečnih sistema, komunikacija putem IPC-a, itd.). U svakoj tački odlučivanja, SELinux procjenjuje operaciju na osnovu učitane politike i sigurnosnog konteksta subjekta i objekta . Ako politika eksplicitno ne daje dozvolu, akcija se odbija, bez obzira na to da li je proces root ili ne.

Načini rada: prinudni, permisivni 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:

• SprovođenjeSELinux je omogućen i u potpunosti primjenjuje pravila. Sve radnje koje nisu dozvoljene pravilima su blokirane i zabilježene.
• DozvoljenoSELinux je aktivan, učitava pravila i označava datotečni sistem, ali ne blokira Bilježi transakcije samo kao da su odbijene. Ovo je idealno za otklanjanje grešaka i prilagođavanje politika.
• invaliditetomSELinux je onemogućen. Ne primjenjuju se nikakve politike niti se vrši označavanje. Sistem se oslanja na klasični DAC model.

Za brze i privremene promjene između prinudnog i permisivnog načina rada, koristi se naredba `setenforce` , gdje je način rada određen kao 0 (dozvoljeni) ili 1 (prinudni). 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, potrebno je urediti datoteku. /etc/selinux/config (ili /etc/sysconfig/selinux u nekim distribucijama) i prilagodite vrijednost direktive SELINUX=disabled|permissive|enforcingPromjene će biti primijenjene pri sljedećem pokretanju i, u mnogim slučajevima, uključivat će ponovno označavanje datotečnog sistema.

Da biste provjerili aktivni način rada, možete koristiti naredbe poput getenforce ili sestatus . Prva jednostavno vraća Enforcing, Permissive ili Disabled; druga pruža potpuniji sažetak SELinux statusa, učitanih politika i aktivnih modula.

Sigurnosni konteksti i sistem označavanja

Srce SELinuxa je njegov sistem sigurnosnih oznaka ili konteksta . Svaka datoteka, proces, mrežni port, socket, uređaj itd. ima pridruženi kontekst koji opisuje kako se može koristiti. Ovaj kontekst se sastoji od nekoliko polja koja zajedno formiraju SELinuxov pogled na taj objekat.

Opći format konteksta je user_u:role_r:type_t:level , s nekim nijansama koje ovise o politici (posebno ako se koristi MLS/MCS). Svako polje ima određenu svrhu: SELinux korisnika, ulogu, tip (također se naziva domen kada se odnosi na procese) i nivo 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, omogućavanje procesima tipa httpd_t pristup datotekama označenim s httpd_sys_content_t ili omogućavanje određenom domenu komunikaciju sa socketima označenim s http_port_t.

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

Tipični primjeri konteksta u sistemu sa ciljanom politikom bili bi:

• system_u:object_r:httpd_sys_content_t:s0 za web sadržaj koji poslužuje Apache ili Nginx.
• sistem_u:objekt_r:kućni_korisnik_t:s0 za korisničke kućne direktorije.
• system_u:system_r:httpd_t:s0 za izvršnu domenu samog web servera.

Raščlamba komponenti SELinux konteksta

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

El Korisnik SELinuxa (po konvenciji sa 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 nezavisan od DAC-a.

El SELinux uloga (sa sufiksom _rOvo definira koje uloge korisnik ili domena mogu usvojiti. 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 SELinux tip ili domen (sufiks _tU praksi, tip je ključni element. Tip opisuje klasu objekta ili domen izvršavanja procesa. Politika specificira koje su interakcije dozvoljene između tipova: koji domeni mogu čitati, pisati, izvršavati ili komunicirati s kojim drugim tipovima objekata.

Nivoi i kategorije se koriste kada su omogućene politike višeslojne 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 istom nivou ili prema gore , te da se podaci izoliraju prema vrlo specifičnim odjeljcima.

SELinux politike: ciljane, stroge, MLS/MCS i modularnost

Sigurnost koju provodi SELinux određena je učitanom politikom . Politika je jednostavno veliki skup pravila koja opisuju koje domene mogu šta raditi na kojim tipovima, kao i druge elemente (prijelazi, pravila označavanja itd.). Distribucije obično paketiraju standardne politike tako da ne morate sve pisati od nule.

Najčešća politika se naziva ciljana . U ovom načinu rada, samo specifični procesi - uglavnom mrežne usluge i visokorizični daemoni poput Apachea, Nginxa, DNS-a, proxyja, SNMP-a, sysloga itd. - izvršavaju se unutar ograničenih domena. Svi ostali korisnički procesi izvršavaju se u "neograničenim" domenama, gdje se u suštini primjenjuje standardna Linux sigurnost, zajedno sa zapisivanjem 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 neskladnost u označavanju ili pravilima može poremetiti standardne tokove rada.

Za okruženja s visokom sigurnošću postoje MLS/MCS (Multi-Level/Multi-Category Security) politike koje koriste 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 se distribuiraju na modularan način . Umjesto jedne monolitne datoteke politike, koriste se odvojeni moduli za specifične usluge, što znatno pojednostavljuje upravljanje i ažuriranja. Ovi moduli se upravljaju alatima poput semodule i semanage module , koji vam omogućavaju da instalirate, uklonite, omogućite ili onemogućite dijelove politike bez ponovnog kompajliranja 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 domen 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 prinudnu primjenu tipova podataka (TE), koja koristi većina distribucija i Android, svaki objekt pripada klasi ( datoteka, direktorij, fifo_datoteka, tcp_socket, proces, itd.) i politika definira koje su dozvole moguće za svaku klasu: čitanje, pisanje, izvršavanje, povezivanje, povezivanje, getattr, otvaranje i tako dalje.

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

dozvoli httpd_t http_port_t:tcp_socket name_bind;

Ovim pravilom, politika ukazuje na to da procesi u domenu httpd_t mogu izvršavati operaciju name_bind na TCP socketima označenim kao 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` se također koriste za grupiranje nekoliko uobičajenih dozvola za datoteke i smanjenje grešaka uzrokovanih propustima.

Interni statusi, AVC i registar odbijenica

Kada se pojavi zahtjev za pristup, SELinux prvo konsultuje Access Vector Cache (AVC) , keš memoriju koja pohranjuje nedavne odluke o pristupu kako bi se ubrzao proces. Ako je odluka već u kešu, koristi se direktno; u suprotnom, upit se šalje zaštitnom zidu (unutrašnji dio SELinuxa u kernelu), koji procjenjuje operaciju na osnovu politike i konteksta subjekta i objekta.

Ako ne postoji pravilo koje eksplicitno dozvoljava traženu radnju, podrazumijevana odluka je odbijanje . Ova filozofija "odbijanja po podrazumijevanim postavkama" jedan je od stubova SELinuxa i ono što mu daje otpornost na dozvoljene greške u konfiguraciji.

Kada dođe do odbijanja u prinudnom režimu, kernel zapisuje poruku tipa avc: odbijeno u sistemskim zapisnicima. U zavisnosti od distribucije, može se pojaviti u /var/log/audit/audit.logu /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 grešaka.

U permisivnom režimu, operacija je dozvoljena, ali se i dalje generiše događaj avc: denied , označen sa permissive=1. Ovo je čisto zlato za izgradnju i podešavanje politika, jer vam omogućava da vidite šta bi narušilo sistem ako bi se sprovođenje propisa implementiralo bez prekidanja normalnog rada.

Integracija SELinuxa u distribucije i Android

U ekosistemu Linux servera i desktop računara, SELinux je podrazumevano omogućen 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 sa fixfiles relabel.

Android je prvobitno uključio SELinux u verziji 4.3 u permisivnom režimu, 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 u potpunosti je integriran od verzije Android 5.0 . Androidova politika se fokusira na izolaciju aplikacija, sistemskih usluga i osjetljivih procesa korištenjem 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 ovo zajedno funkcionira 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.

Poređenje sa AppArmorom i drugim LSM-ovima

U mnogim diskusijama, neizbježno se javlja poređenje između SELinuxa i AppArmora , jer 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 sistemu (datoteke, procesi, soketi, portovi, uređaji, IPC-ovi, itd.) dodjeljuje se oznaka. Odluke o pristupu donose se na osnovu konteksta subjekta i objekta, bez obzira na tačnu putanju datoteke. Ovo čini sistem stabilnijim u suočavanju s promjenama strukture direktorija ili alternativnim prikazima sistema datoteka (chroot, kontejneri, bind mount-ovi, itd.).

S druge strane, AppArmor primjenjuje politiku usmjerenu na zadatke i zasnovanu na putanjama. Definira profile za svaki program, specificirajuć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 sistema.

Oba dijele princip zabrane po defaultu, ali ga primjenjuju različito: AppArmor po defaultu zabranjuje samo zadatke koje pokriva profilima, dok SELinux, kada je u striktnom režimu, proširuje taj princip na cijeli sistem i sve označene objekte. Kao rezultat toga, SELinux obično nudi dublji nivo ograničenja , po cijenu opsežnije i složenije politike.

Praktični alati za upravljanje SELinuxom

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

Da biste pregledali sigurnosni kontekst datoteka i procesa, možete koristiti opciju -Z u uobičajenim naredbama kao što su ls, ps ili id. Na primjer, ls -Z Pored DAC dozvola, prikazat će i SELinux kontekst svake datoteke, što vam omogućava da brzo provjerite je li označavanje očekivano.

Naredba `chcon` ("promjena konteksta") vam omogućava da ručno izmijenite cijeli kontekst datoteke ili samo određene dijelove (ulogu, tip, raspon) koristeći opcije kao što su `-r`, `-to` i `-l`. Korisna je za jednokratne ispravke, ali je važno zapamtiti da se vaše promjene mogu izgubiti ako se označavanje ponovo primijeni prema pravilima pomoću alata kao što su `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 prijave 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 ovo bez potrebe za ponovnim kompajliranjem cijele politike iz izvornog koda.

Za provjeru i promjenu stanja logičkih vrijednosti - malih prekidača koji omogućavaju ili onemogućavaju blokove pravila unutar politike - koriste se getsebool i setsebool , pored same logičke vrijednosti setsebool . Tipična logička vrijednost je httpd_enable_homedirs, koja, kada je aktivna, omogućava web serveru pristup kućnim direktorijima korisnika (korisno za ~user/public_html/).

Konačno, naredbe poput fixfiles omogućavaju vam da prisilno promijenite označavanje datotečnog sistema u skladu s definiranim pravilima, a semodule se brine o instaliranju, popisivanju, omogućavanju ili onemogućavanju modula pravila (.pp) koje pakira i distribuira referentna politika ili administrator.

Kreiranje i prilagođavanje 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 kreirate 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 datoteka pomoću ` semanage fcontext` i njihovom primjenom pomoću `restorecon`, koristeći regularne izraze za obuhvatanje cijelih stabala direktorija.

Sistem se zatim obično stavlja u permisivni način rada za tu mašinu (ili, u nekim slučajevima, za određenu domenu) i aplikaciji je dozvoljeno da normalno radi dok SELinux bilježi sve naredbe `avc: denied` koje bi se mogle pojaviti. Ovi zapisnici, obično analizirani alatima poput audit2allow , koriste se za izdvajanje kandidata za pravila.

Referentne politike su obično 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 javne interfejse koje drugi moduli mogu ponovo koristiti. Sve se ovo kompajlira u .pp module korištenjem make naredbe i učitava se pomoću semodule.

Ključno je ne vjerovati slijepo svemu što audit2allow predlaže: on ima tendenciju da bude više popustljiv nego što je strogo potrebno . Idealno bi bilo da ručno pregledate predložena pravila, kreirate nove tipove gdje je to prikladno kako biste odvojili osjetljive podatke od nebitnih podataka i, kada odbijena operacija nije kritična, razmislite o korištenju dontaudit pravila kako biste zaustavili snimanje šuma bez davanja 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 brzim prilagođavanjem politike određenim kontejnerima bez potrebe za učenjem cijelog jezika politika od nule.

Cijeli ovaj ekosistem konteksta, modularnih politika, logičkih vrijednosti i alata za upravljanje čini SELinux izuzetno robusnom i fleksibilnom sigurnosnom platformom . Uz određena početna ulaganja u učenje, omogućava vrlo precizno ograničavanje onoga što svaka usluga ili aplikacija može učiniti, drastično jačajući površinu sistema za napad protiv exploita, zlonamjernog softvera i ljudskih grešaka.