SELinux-sikkerhed: Styr dit Linux-system ned til millimeteren

Informatic Digital » Recursos » SELinux-sikkerhed: Styr dit Linux-system ned til millimeteren

SELinux lyder måske som teknologi forbeholdt kernel-nørder, men det er faktisk et af de mest kraftfulde sikkerhedsværktøjer, der findes i Linux i dag . Hvis du administrerer servere, Docker-containersikkerhed , cloud-infrastruktur eller endda lidt følsomme stationære computere, gør det hele forskellen på et system, der simpelthen er "velkonfigureret", og et, der er svært at kompromittere, selv med zero-day-sårbarheder.

Trods sit ry for at være "kompliceret", tilbyder SELinux en meget logisk model: den definerer, hvad hver proces kan gøre, og hvilke objekter den kan kommunikere med, og hvis noget afviger fra det script, stopper kernen det øjeblikkeligt . I stedet for blindt at stole på, at root vil opføre sig korrekt, eller at dine dæmoner ikke har fejl, håndhæver SELinux obligatorisk adgangskontrol, der gælder selv for superbrugeren, ved hjælp af meget detaljerede etiketter og politikker.

Hvad er SELinux, og hvilket problem løser det?

Security-Enhanced Linux (SELinux) er et Linux-kernesikkerhedsmodul baseret på LSM (Linux Security Modules). Det blev oprindeligt udviklet af NSA i samarbejde med Red Hat og andre partnere, og siden kerneversion 2.6 har det været en officiel del af kernen. Det er ikke en separat applikation, men snarere en kerneudvidelse, der tilføjer et obligatorisk adgangskontrolsystem (MAC) og rollebaseret adgangskontrol (RBAC).

I modsætning til den klassiske Unix diskretionære adgangskontrol (DAC) – ejer , gruppe, andre og rwx-tilladelser – er adgangsbeslutninger i SELinux ikke baseret på filejerens valg, men snarere på en global politik fastsat af sikkerhedsadministratoren. DAC er stadig til stede og har forrang: hvis DAC nægter, griber SELinux ikke ind; men selvom DAC tillader det, kan SELinux stadig blokere handlingen i henhold til sin politik.

SELinux-arkitekturen adskiller komponenterne tydeligt: ​​på den ene side kernekoden, der træffer sikkerhedsbeslutninger , og på den anden side policymodulerne, der definerer, hvad der er tilladt, og hvad der ikke er. Denne adskillelse giver mulighed for at justere reglerne uden at rekompilere kernen og strømliner antallet af komponenter, der kan påvirke systemsikkerheden.

SELinux er blevet implementeret som standard i distributioner som Fedora, Red Hat Enterprise Linux, CentOS og Scientific Linux, og er også dybt integreret i systemer som Android, hvor det bruges til at begrænse systemprocesser og apps til meget specifikke domæner. I BSD- og GNU/Linux-verdenen findes der alternativer som AppArmor, TOMOYO og TrustedBSD (på macOS/FreeBSD), men SELinux skiller sig ud ved det granularitetsniveau, det tilbyder over alle systemobjekter.

Fra DAC til MAC: hvorfor den klassiske model ikke længere er nok

I et traditionelt Unix-system administreres Domain-Object-modellen ved hjælp af DAC: hver fil eller ressource har en ejer og tilladelser, og enhver proces, der kører som den pågældende bruger, kan gøre, hvad den vil med disse ressourcer . Det betyder, at hvis en daemon kører som root, kan enhver udnyttelig fejl åbne døren for at kontrollere halvdelen af ​​systemet med sin root-kontekst.

Typiske eksempler omfatter databaser, hvis datafiler kun burde manipuleres via DBMS'et, men som faktisk kan læses og modificeres af processer med rod-UID'et ; eller kritiske dæmoner, der kører med for mange rettigheder. En programmeringsfejl, et bufferoverløb eller dårlig inputvalidering kan gøre tjenesten til en motorvej til hele systemet.

SELinux tilføjer et obligatorisk adgangskontrollag (MAC) oven på DAC. "Obligatorisk" betyder, at adgangskontrol defineres centralt af administratoren gennem politikker, og hverken brugere eller processer kan lempe disse regler på egen hånd. Operativsystemet håndhæver disse politikker ved at evaluere hver relevant kerneoperation, før den tillades.

Kernen forespørger SELinux ved hjælp af LSM-hooks ved hvert følsomt systemkald (åbning af filer, oprettelse af sockets, montering af filsystemer, kommunikation via IPC osv.). Ved hvert beslutningspunkt evaluerer SELinux operationen baseret på den indlæste politik og sikkerhedskonteksten for subjektet og objektet . Hvis politikken ikke eksplicit giver tilladelse, afvises handlingen, uanset om processen er root eller ej.

Driftstilstande: håndhævende, tilladt og deaktiveret

SELinux kan operere i tre klart differentierede driftstilstande, som er vigtige at forstå for at undgå at gå amok i produktionen:

• HåndhævelseSELinux er aktiveret og håndhæver politikken fuldt ud. Alle handlinger, der ikke er tilladt af reglerne, blokeres og logges.
• TilladendeSELinux er aktiv, indlæser politikken og navngiver filsystemet, men blokerer ikke Den registrerer kun transaktionerne, som om de var blevet afvist. Dette er ideelt til fejlfinding og justering af politikker.
• handicappetSELinux er deaktiveret. Der anvendes ingen politikker, og der udføres ingen tagging. Systemet er afhængigt af den klassiske DAC-model.

For hurtige og midlertidige ændringer mellem håndhævende og tilladte tilstande bruges kommandoen `setenforce` , hvor tilstanden er angivet som 0 (tilladende) eller 1 (håndhævende). Det er vigtigt at vide, at denne ændring er volatil: efter næste genstart vender tilstanden tilbage til den, der er defineret i konfigurationen.

Hvis du har brug for en permanent ændring, skal du redigere filen. /etc/selinux/config (eller /etc/sysconfig/selinux i nogle distributioner) og juster værdien af ​​direktivet SELINUX=disabled|permissive|enforcingÆndringerne vil blive anvendt ved næste opstart og vil i mange tilfælde involvere omnavngivning af filsystemet.

For at kontrollere den aktive tilstand kan du bruge kommandoer som getenforce eller sestatus . Førstnævnte returnerer blot Enforceing, Permissive eller Disabled; sidstnævnte giver en mere komplet oversigt over SELinux-status, indlæste politikker og aktive moduler.

Sikkerhedskontekster og mærkningssystem

Hjertet i SELinux er dets system af sikkerhedsetiketter eller kontekster . Hver fil, proces, netværksport, socket, enhed osv. har en tilknyttet kontekst, der beskriver, hvordan den kan bruges. Denne kontekst er sammensat af flere felter, der tilsammen danner SELinux' visning af det pågældende objekt.

Det generelle format for en kontekst er user_u:role_r:type_t:level , med nogle nuancer afhængigt af politikken (især hvis MLS/MCS bruges). Hvert felt har et specifikt formål: SELinux-brugeren, rollen, typen (også kaldet domæne, når der refereres til processer) og følsomhedsniveauet eller -kategorien.

I praksis er det mest kritiske element typen (det tredje felt), da langt de fleste politikregler er formuleret som relationer mellem typer . For eksempel at tillade processer af typen httpd_t at få adgang til filer mærket httpd_sys_content_t, eller at tillade et specifikt domæne at kommunikere med sockets mærket http_port_t.

Disse kontekster gemmes som udvidede filsystemattributterDerfor er det vigtigt at bruge filsystemer, der understøtter xattrs (såsom ext4, XFS osv.). I tilfælde af processer eksponeres den aktuelle kontekst og andre relaterede kontekster gennem pseudo-filsystemet. /proc/<pid>/attr/ i filer som current, exec, fscreate, prev, sockcreate eller keycreate.

Typiske eksempler på kontekster i et system med målrettet politik ville være:

• system_u:object_r:httpd_sys_content_t:s0 for webindhold serveret af Apache eller Nginx.
• system_u:objekt_r:hjemmebruger_t:s0 for brugernes hjemmemapper.
• system_u:system_r:httpd_t:s0 for selve webserverens udførelsesdomæne.

Opdeling af komponenterne i SELinux-konteksten

Når du støder på en kontekst som unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , kan det virke som hieroglyffer, men hvert stykke svarer til et specifikt koncept inden for SELinux og dets referencepolitik.

El SELinux-bruger (efter konvention med suffiks) _uDette er ikke det samme som Unix-brugeren i /etc/passwd. SELinux vedligeholder sin egen brugerdatabase og knytter dem til Linux-brugere. En SELinux-bruger kan gruppere flere Unix-brugere, fordi ideen er, at MAC-laget skal være uafhængigt af DAC'en.

El SELinux-rolle (med suffiks _rDette definerer, hvilke roller en bruger eller et domæne kan påtage sig. Hvis det bruges strengt, kaldes det fuld RBAC. De fleste filobjekter bruger rollen object_r, mens roller som system_r, user_r, staff_r eller sysadm_r anvendes på processer afhængigt af den sikkerhedskontekst, de skal påtage sig.

El SELinux-type eller -domæne (suffiks _tI praksis er typen det afgørende element. Typen beskriver objektklassen eller udførelsesdomænet for en proces. Politikken specificerer, hvilke interaktioner der er tilladt mellem typer: hvilke domæner kan læse, skrive, udføre eller kommunikere med hvilke andre typer objekter.

Niveauer og kategorier bruges, når politikker for sikkerhed på flere niveauer (MLS) eller sikkerhed på flere kategorier (MCS) er aktiveret. Følsomheder er hierarkiske (f.eks. s0, s1 osv.), mens kategorier ikke er det (c0, c1, c2 osv.). I meget kritiske miljøer – for eksempel visse offentlige organisationer – bruges de til at sikre, at data kun kan læses nedad og skrives til samme niveau eller opad , og til at isolere data i henhold til meget specifikke sektioner.

SELinux-politikker: målrettede, strenge, MLS/MCS og modularitet

Den sikkerhed, der håndhæves af SELinux, bestemmes af den indlæste politik . En politik er simpelthen et stort sæt regler, der beskriver, hvilke domæner der kan gøre hvad på hvilke typer, såvel som andre elementer (overgange, taggingregler osv.). Distributioner pakker normalt standardpolitikker, så du ikke behøver at skrive alt fra bunden.

Den mest almindelige politik kaldes målrettet . I denne tilstand kører kun specifikke processer – primært netværkstjenester og højrisiko-dæmoner som Apache, Nginx, DNS, proxies, SNMP, syslog osv. – inden for begrænsede domæner. Alle andre brugerprocesser kører i "ubegrænsede" domæner, hvor standard Linux-sikkerhed i bund og grund anvendes, sammen med logføring af visse handlinger.

Der er også den strenge politik , hvor stort set alle processer er begrænset af en specifik politik. Det er meget mere sikkert, men det kan også være betydeligt vanskeligere at vedligeholde, hvis modellen ikke er godt forstået, fordi enhver uoverensstemmelse i mærkning eller regler kan forstyrre standardarbejdsgange.

For miljøer med høj sikkerhed findes der MLS/MCS-politikker (Multi-Level/Multi-Category Security) , der udnytter følsomheder og kategorier til at indføre endnu finere kontroller. Disse er typiske for meget rigide militære eller administrative miljøer og bruges sjældent uden for specifikke kontekster på grund af deres høje operationelle kompleksitet.

Moderne politikker distribueres modulært . I stedet for en enkelt monolitisk politikfil bruges separate moduler til specifikke tjenester, hvilket forenkler administration og opdateringer betydeligt. Disse moduler administreres med værktøjer som semodule og semanage module , som giver dig mulighed for at installere, fjerne, aktivere eller deaktivere dele af politikken uden at skulle kompilere hele politikken hver gang.

Hvordan SELinux beslutter: subjekter, objekter, klasser og tilladelser

Når en proces (subjektet) forsøger at tilgå en ressource (objektet), stiller SELinux konceptuelt spørgsmålet: "Kan et domæne af typen X udføre operation Y på et objekt af typen Z, der tilhører klasse C?" . Svaret søges derefter i politikken gennem de definerede regler.

I Type Enforcement (TE)-politikker, som bruges af de fleste distributioner og Android, tilhører hvert objekt en klasse (fil, dir, fifo_file, tcp_socket, process osv.), og politikken definerer, hvilke tilladelser der er mulige for hver klasse: læse, skrive, udføre, binde, forbinde, getattr, åbne og så videre.

TE-regler udtrykkes meget direkte. Et grundlæggende eksempel ville være:

tillad httpd_t http_port_t:tcp_socket navn_bind;

Med denne regel angiver politikken, at processer i httpd_t-domænet kan udføre name_bind-operationen på TCP-sockets mærket http_port_t. Tilgangen fokuserer på objekttyper og -klasser, ikke specifikke stier , hvilket forhindrer overraskelser, når man flytter filer eller ændrer mappestrukturer.

I Android bruges SELinux-attributter for eksempel til at gruppere typer under mere generelle betegnelser som `appdomain` , så en enkelt regel kan gælde for flere domæner (`untrusted_app`, `isolated_app` osv.) uden at gentage definitioner. Makroer som `rw_file_perms` bruges også til at gruppere flere almindelige filtilladelser og reducere fejl forårsaget af overseelser.

Interne statusser, AVC og afslagsregister

Når en adgangsanmodning opstår, konsulterer SELinux først Access Vector Cache (AVC) , en cache, der gemmer de seneste adgangsbeslutninger for at fremskynde processen. Hvis beslutningen allerede er i cachen, bruges den direkte; ellers forespørges firewallen (den interne del af SELinux i kernen), som evaluerer operationen baseret på politikken og emne- og objektkonteksten.

Hvis der ikke er en regel, der eksplicit tillader den ønskede handling, er standardbeslutningen at afvise . Denne "afvis som standard"-filosofi er en af ​​grundpillerne i SELinux og det, der giver den dens robusthed mod tilladte konfigurationsfejl.

Når der sker en afvisning i håndhævelsestilstand, logger kernen en besked af typen avc: afvist i systemloggene. Afhængigt af distributionen kan det vises i /var/log/audit/audit.logi /var/log/messages eller blive fanget af audittd-dæmonen. Disse beskeder inkluderer proceskonteksten (context), objektkonteksten (tcontext), klassen, den anmodede handling og andre data, der er meget nyttige til fejlfinding.

I permissiv tilstand er handlingen tilladt, men hændelsen avc: denied genereres stadig , markeret med permissive=1. Dette er rent guld til at opbygge og justere politikker, fordi det giver dig mulighed for at se, hvad der ville ødelægge systemet, hvis håndhævelse blev implementeret uden at afbryde den normale drift.

Integrering af SELinux i distributioner og Android

I Linux-server- og desktop-økosystemet er SELinux aktiveret som standard i Fedora, RHEL, CentOS og derivaterDebian og Ubuntu tilbyder fuld understøttelse i deres kerner og pakker, selvom aktivering normalt er valgfri og kræver installation af pakker som selinux-basics, selinux-policy-default og auditd, efterfulgt af global retagging med fixfiles relabel.

Android integrerede oprindeligt SELinux i version 4.3 i permissiv tilstand, overgik til delvis brug i 4.4 (kun for kritiske domæner som installd, netd, vold og zygote) og har været fuldt integreret siden Android 5.0 . Androids politik fokuserer på at isolere apps, systemtjenester og følsomme processer ved hjælp af typer og attributter med det formål at minimere virkningen af ​​en kompromis på nogen af ​​disse komponenter.

Android bruger koncepter som typen untrusted_app til almindelige applikationsprocesser, appdomain-attributter til at gruppere appdomæner og MLS/MCS-kategorier til at isolere data mellem apps og mellem fysiske brugere. Alt dette arbejder sammen for at forhindre en kompromitteret applikation i at undslippe sin sandkasse, selvom den får meget brede brugertilladelser.

Vigtigt: Android forenkler SELinux-modellen ved at ignorere brugere, roller og avancerede følsomheder. Der er kun én SELinux-bruger (u), to grundlæggende roller (r for subjekter og object_r for objekter), og følsomheden er altid s0. Det er kategorierne, der gør forskellen for dataisolering.

Sammenligning med AppArmor og andre LSM'er

I mange diskussioner opstår sammenligningen mellem SELinux og AppArmor uundgåeligt , da begge er Linux-sikkerhedsmoduler og tilbyder MAC'er. Deres tilgange er dog ret forskellige, og det er værd at forstå dette, før du vælger den ene eller den anden til dit miljø.

SELinux definerer en politik centreret omkring objekter og deres typer: hvert objekt i systemet (filer, processer, sockets, porte, enheder, IPC'er osv.) tildeles en etiket. Adgangsbeslutninger træffes baseret på emne- og objektkontekster, uden at være afhængige af den nøjagtige filsti. Dette gør systemet mere stabilt i lyset af ændringer i mappestrukturen eller alternative filsystemvisninger (chroot, containere, bind mounts osv.).

AppArmor anvender derimod en opgavecentreret , stibaseret politik. Den definerer profiler for hvert program og specificerer hvilke filstier, porte osv. det kan tilgå, og med hvilke tilladelser. Den er mere intuitiv at konfigurere og generelt mere brugervenlig for administratorer, der ikke ønsker at blive eksperter i SELinux, men dens kontrol er noget mindre detaljeret og mere afhængig af filsystemets struktur.

Begge deler princippet om at nægte adgang som standard, men de anvender det forskelligt: ​​AppArmor nægter som standard kun de opgaver, den dækker med profiler, mens SELinux, når den er i streng tilstand, udvider det til hele systemet og alle taggede objekter. Som et resultat tilbyder SELinux typisk et dybere niveau af indespærring på bekostning af en mere omfattende og kompleks politik.

Praktiske værktøjer til administration af SELinux

Arbejde med SELinux er afhængigt af en række kommandolinjeværktøjer, der forenkler administrationen af ​​tilstande, tagging, booleske værdier og policymoduler. Selvom dette kan virke som et overvældende arsenal i starten, dækker et par værktøjer de fleste daglige opgaver.

For at se sikkerhedskonteksten for filer og processer kan du bruge indstillingen -Z i almindelige kommandoer som ls, ps eller id. For eksempel, ls -Z Udover DAC-tilladelser viser den SELinux-konteksten for hver fil, så du hurtigt kan kontrollere, om taggingen er som forventet.

Kommandoen `chcon` ("ændre kontekst") giver dig mulighed for manuelt at ændre hele konteksten for en fil eller kun specifikke dele (rolle, type, område) ved hjælp af indstillinger som `-r`, `-to` og `-l`. Den er nyttig til engangsrettelser, men det er vigtigt at huske, at dine ændringer kan gå tabt, hvis mærkningen genanvendes i henhold til politikken ved hjælp af værktøjer som `restorecon` eller `fixfiles`.

Semanage- værktøjet er den schweiziske armékniv inden for runtime-policystyring. Med forskellige underkommandoer kan du administrere persistente filkontekster (fcontext), login-tilknytninger mellem Linux- og SELinux-brugere (login), SELinux-brugere og deres roller (user), taggede porte (port), booleske værdier og endda policymoduler. Alt dette uden at skulle rekompilere hele policyen fra kildekoden.

For at kontrollere og ændre tilstanden af ​​boolske værdier – små parametere, der aktiverer eller deaktiverer blokke af regler i politikken – bruges getsebool og setsebool , ud over selve setsebool-værdien . En typisk boolsk værdi er httpd_enable_homedirs, som, når den er aktiv, giver webserveren adgang til brugernes hjemmemapper (nyttigt for ~user/public_html/).

Endelig giver kommandoer som fixfiles dig mulighed for at gennemtvinge en komplet omlabeling af filsystemet i henhold til de definerede regler, og semodule tager sig af at installere, vise, aktivere eller deaktivere politikmoduler (.pp), der er pakket og distribueret af referencepolitikken eller af administratoren.

Oprettelse og justering af tilpassede politikker

Når en applikation ikke har sit eget SELinux-modul, eller du har brug for mere specifik begrænsning, er det tid til at komme i gang og oprette brugerdefinerede politikker . Det lyder måske kompliceret, men arbejdsgangen er ret veldefineret, hvis du følger visse trin omhyggeligt.

Det første trin er at sikre, at de relevante objekter (eksekverbare filer, datamapper, sockets osv.) er mærket med passende typer. Dette kan opnås ved at definere filkontekstregler med ` semanage fcontext` og anvende dem med `restorecon`, hvor regulære udtryk bruges til at omfatte hele mappetræer.

Systemet sættes derefter typisk i tilladt tilstand for den pågældende maskine (eller i nogle tilfælde for et specifikt domæne), og applikationen får lov til at køre normalt, mens SELinux logger alle ` avc: denied`-sætningerne, der ville være forekommet. Disse logfiler, normalt analyseret med værktøjer som audit2allow , bruges til at udtrække kandidatregler.

Referencepolitikker er typisk struktureret i tre filer pr. applikation: en .te-fil, der indeholder TE-regler (allow, type, domain_type osv.), en .fc-fil, der indeholder filkontekstregler, og en .if-fil, der indeholder offentlige grænseflader, som andre moduler kan genbruge. Alt dette kompileres til .pp-moduler ved hjælp af make og indlæses med semodule.

Det er afgørende ikke at stole blindt på alt, hvad audit2allow foreslår: det har en tendens til at være mere tilladende end strengt nødvendigt . Ideelt set bør du manuelt gennemgå de foreslåede regler, oprette nye typer, hvor det er relevant, for at adskille følsomme data fra irrelevante data, og når en afvist handling ikke er kritisk, overveje at bruge dontaudit-regler til at stoppe optagelse af støj uden at give tilladelser.

I miljøer som SUSE Linux Micro eller Android leveres yderligere værktøjer (f.eks. Udica til at generere containerpolitikker fra JSON-beskrivelser), der automatiserer en del af processen ved hurtigt at tilpasse politikken til specifikke containere uden at skulle lære hele politiksproget fra bunden.

Hele dette økosystem af kontekster, modulære politikker, booleske værdier og administrationsværktøjer gør SELinux til en ekstremt robust og fleksibel sikkerhedsplatform . Med en vis indledende investering i læring muliggør det en meget præcis begrænsning af, hvad hver tjeneste eller applikation kan gøre, hvilket drastisk hærder systemets angrebsflade mod exploits, malware og menneskelige fejl.