RHCSA-serien: Obligatorisk adgangskontrol med SELinux i RHEL 7 - Del 13

I løbet af denne serie har vi udforsket i detaljer mindst to adgangskontrolmetoder: standard ugo/rwx-tilladelser (Konfigurer ACL'er på filsystemer - Del 7).

Selvom det er nødvendigt som tilladelser på første niveau og adgangskontrolmekanismer, har de nogle begrænsninger, der behandles af Security Enhanced Linux (også kendt som SELinux).

En af sådanne begrænsninger er, at en bruger kan udsætte en fil eller mappe for et sikkerhedsbrud gennem en dårligt uddybet chmod-kommando og dermed forårsage en uventet udbredelse af adgangsrettigheder. Som et resultat kan enhver proces, der startes af den bruger, gøre som det vil med de filer, der ejes af brugeren, hvor endelig en ondsindet eller på anden måde kompromitteret software kan opnå rodniveauadgang til hele systemet.

Med disse begrænsninger i tankerne udtænkte United States National Security Agency (NSA) først SELinux, en fleksibel obligatorisk adgangskontrolmetode, der begrænser processernes evne til at få adgang til eller udføre andre operationer på systemobjekter (såsom filer, kataloger, netværksporte osv.) til den mindste tilladelsesmodel, som kan ændres senere efter behov. Med få ord gives hvert element i systemet kun den nødvendige adgang til at fungere.

I RHEL 7 er SELinux integreret i selve kernen og er som standard aktiveret i håndhævelsestilstand. I denne artikel vil vi kort forklare de grundlæggende begreber, der er forbundet med SELinux og dens drift.

SELinux-tilstande

SELinux kan fungere på tre forskellige måder:

Håndhævelse: SELinux nægter adgang baseret på SELinux-politikregler, et sæt retningslinjer, der styrer sikkerhedsmotoren.
Tilladelig: SELinux nægter ikke adgang, men benægtelser logges for handlinger, der ville være nægtet, hvis de kører i håndhævelsestilstand.
Deaktiveret (selvforklarende).

Kommandoen getenforce viser den aktuelle tilstand af SELinux, mens setenforce (efterfulgt af en 1 eller en 0) bruges til at ændre tilstanden til henholdsvis Enforcing eller Permissive under kun den aktuelle session.

For at opnå vedholdenhed på tværs af logouts og genstart, skal du redigere /etc/selinux/config -filen og indstille SELINUX-variablen til enten håndhævende, tilladende eller deaktiveret:

# getenforce
# setenforce 0
# getenforce
# setenforce 1
# getenforce
# cat /etc/selinux/config

Normalt bruger du setenforce til at skifte mellem SELinux-tilstande (håndhævelse til tilladende og tilbage) som et første fejlfindingstrin. Hvis SELinux i øjeblikket er indstillet til at håndhæve, mens du oplever et bestemt problem, og det samme forsvinder, når du indstiller det til tilladende, kan du være sikker på at du ser på et SELinux-tilladelsesproblem.

SELinux-sammenhænge

En SELinux-kontekst består af et adgangskontrolmiljø, hvor beslutninger træffes baseret på SELinux-bruger, rolle og type (og eventuelt et niveau):

En SELinux-bruger supplerer en almindelig Linux-brugerkonto ved at kortlægge den til en SELinux-brugerkonto, som igen bruges i SELinux-sammenhængen til processer i den session, for eksplicit at definere deres tilladte roller og niveauer.
Begrebet rolle fungerer som et mellemled mellem domæner og SELinux-brugere, idet det definerer, hvilke procesdomæner og filtyper der er adgang til. Dette vil beskytte dit system mod sårbarhed over for privilegier eskaleringsangreb.
En type definerer en SELinux-filtype eller et SELinux-procesdomæne. Under normale omstændigheder er processer forhindret i at få adgang til filer, som andre processer bruger, og i at få adgang til andre processer, og adgang er således kun tilladt, hvis der findes en specifik SELinux-politikregel, der tillader det.

Lad os se, hvordan alt dette fungerer gennem følgende eksempler.

I Securing SSH - Part 8 forklarede vi, at ændring af standardporten, hvor sshd lytter, er en af de første sikkerhedsforanstaltninger for at sikre din server mod eksterne angreb. Lad os redigere filen /etc/ssh/sshd_config og indstille porten til 9999:

Port 9999

Gem ændringerne, og genstart sshd:

# systemctl restart sshd
# systemctl status sshd

Som du kan se, kunne sshd ikke starte. Men hvad skete der?

En hurtig inspektion af /var/log/audit/audit.log indikerer, at sshd er nægtet tilladelse til at starte på port 9999 (SELinux-logmeddelelser inkluderer ordet "AVC", så de let kan identificeres fra andre meddelelser) fordi det er en reserveret port til JBoss Management-tjenesten:

# cat /var/log/audit/audit.log | grep AVC | tail -1

På dette tidspunkt kan du deaktivere SELinux (men gør det ikke!) Som forklaret tidligere og prøve at starte sshd igen, og det skal fungere. Dog kan semanageværktøjet fortælle os, hvad vi har brug for at ændre, for at vi kan starte sshd i den port, vi vælger uden problemer.

Løb,

# semanage port -l | grep ssh

for at få en liste over de porte, hvor SELinux tillader sshd at lytte på.

Så lad os ændre porten i /etc/ssh/sshd_config til Port 9998, tilføje porten til ssh_port_t-konteksten og genstarte derefter tjenesten:

# semanage port -a -t ssh_port_t -p tcp 9998
# systemctl restart sshd
# systemctl is-active sshd

Som du kan se, blev tjenesten startet med succes denne gang. Dette eksempel illustrerer det faktum, at SELinux kontrollerer TCP-portnummeret til sin egen porttype interne definitioner.

Dette er et eksempel på, at SELinux administrerer en proces, der får adgang til en anden proces. Hvis du skulle implementere mod_security og mod_evasive sammen med Apache på din RHEL 7-server, skal du give httpd adgang til sendmail for at sende en mailmeddelelse i kølvandet på et (D) DoS-angreb. I den følgende kommando skal du udelade -P-flag, hvis du ikke ønsker, at ændringen skal være vedvarende på tværs af genstart.

# semanage boolean -1 | grep httpd_can_sendmail
# setsebool -P httpd_can_sendmail 1
# semanage boolean -1 | grep httpd_can_sendmail

Som du kan se fra ovenstående eksempel, er SELinux boolske indstillinger (eller bare booleanske) sande/falske regler indlejret i SELinux-politikker. Du kan liste alle booleanske med semanage boolean -l , og alternativt rør den til grep for at filtrere output.

Antag at du betjener et statisk websted ved hjælp af en anden mappe end standardkataloget (/var/www/html ), siger/websites (dette kan være tilfældet, hvis du gemmer dine webfiler i en delt netværksdrev, for eksempel, og har brug for at montere det på/websites).

en). Opret en index.html-fil inde/websteder med følgende indhold:

<html>
<h2>SELinux test</h2>
</html>

Hvis du gør,

# ls -lZ /websites/index.html

du vil se, at filen index.html er mærket med standard_t SELinux-typen, som Apache ikke kan få adgang til:

b). Skift DocumentRoot-direktivet i /etc/httpd/conf/httpd.conf til/websites og glem ikke at opdatere den tilsvarende Directory-blok. Genstart derefter Apache.

c). Gå til http:/ , og du skal få et 503 forbudt HTTP-svar.

d). Dernæst skal du ændre etiketten på/websites rekursivt til typen httpd_sys_content_t for at give Apache skrivebeskyttet adgang til den mappe og dens indhold:

# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Endelig skal du anvende SELinux-politikken oprettet i d):

# restorecon -R -v /websites

Genstart Apache og gennemse til http:/ igen, og du vil se html-filen vises korrekt:

Resumé

I denne artikel har vi gennemgået det grundlæggende i SELinux. Bemærk, at på grund af emnets omfang er en fuldstændig detaljeret forklaring ikke mulig i en enkelt artikel, men vi mener, at principperne i denne vejledning vil hjælpe dig med at komme videre til mere avancerede emner, hvis du ønsker det.

Lad mig, hvis jeg har det, anbefale to vigtige ressourcer til at begynde med: RHEL 7 SELinux bruger- og administratorvejledning.

Tøv ikke med at fortælle os, hvis du har spørgsmål eller kommentarer.