1. Innledning
Security-Enhanced Linux (SELinux) er en Linux-kjernemodul og et sikkerhetsundersystem av Linux.
SELinux ble hovedsakelig utviklet av NSA. Linux-kjerner 2.6 og nyere integrerer allerede SELinux-moduler.
SELinux er veldig komplekst og har mye konseptuelt stoff som er vanskelig å lære. Mange Linux-systemadministratorer har slått av SELinux fordi de synes det er problematisk.
Hvis du mestrer SELinux og bruker det riktig, tror jeg hele systemet i praksis kan nå punktet hvor det er "uforgjengelig" (husk alltid at det ikke finnes absolutt sikkerhet).
Å mestre de grunnleggende konseptene i SELinux samt enkle konfigurasjonsmetoder er et obligatorisk kurs for enhver Linux-systemadministrator.
Denne artikkelen er basert på CentOS 7.4.1708.
Denne artikkelen er utelukkende en personlig læringsopplevelse som deling og utveksling, feil er uunngåelige, kun til referanse! Hvis du finner en feil, vennligst påpek det, tusen takk!
2. SELinux' rolle og tillatelsesstyringsmekanismen
2.1 SELinux' rolle
Hovedfunksjonen til SELinux er å minimere ressursene som kan nås av tjenesteprosesser i systemet (prinsippet om minste privilegium).
Tenk deg at hvis en nettverkstjeneste som kjører som root har en 0day-sårbarhet, kan hackere utnytte denne sårbarheten til å gjøre hva de vil på serveren din som root. Er det ikke skummelt?
SELinux er her for å løse dette problemet.
2.2 DAC
I et operativsystem som ikke bruker SELinux, er faktoren som avgjør om en ressurs kan nås om ressursen har tillatelsene til den tilsvarende brukeren (lese, skrive, kjøre).
Så lenge prosessen som får tilgang til denne ressursen oppfyller de ovennevnte betingelsene, kan den nås.
Det mest fatale problemet er at root-brukere ikke er underlagt noen regulering, og alle ressurser i systemet kan nås uten restriksjoner.
Hoveddelen av denne tillatelseshåndteringsmekanismen er brukeren, også kjent som autonom tilgangskontroll (DAC).
2.3 MAC
I et operativsystem som bruker SELinux, er faktorene som avgjør om en ressurs kan nås ikke bare de ovennevnte faktorene, men også om hver type prosess har tilgang til en bestemt type ressurs.
På denne måten, selv om en prosess kjører som rot, er det nødvendig å fastslå hvilken type prosess og hvilke typer ressurser som er tillatt å få tilgang til før man bestemmer om tilgangen skal tillates. Det aktive rommet i prosessen kan også komprimeres til et minimum.
Selv en tjenesteprosess som kjører som root har vanligvis bare tilgang til de ressursene den trenger. Selv om et program er sårbart, er omfanget av påvirkningen begrenset til ressursene det har tilgang til. Sikkerheten er sterkt økt.
Hoveddelen av denne tillatelsesstyringsmekanismen er prosessen, også kjent som obligatorisk tilgangskontroll (MAC).
MAC deles inn i to måter, den ene kalles Category Security (MCS)-modus, og den andre kalles Multi-Level Security (MLS)-modus.
Følgende handlinger er i MCS-modus.
2.4 Sammenligning av DAC og MAC
Her er et bilde for å illustrere.
Som du kan se, i DAC-modus, så lenge den tilsvarende katalogen har tillatelsene til den tilsvarende brukeren, kan den nås. I MAC-modus er den også begrenset av rekkevidden av kataloger som prosesser har tilgang til.
3. Grunnleggende konsepter i SELinux
3.1 Emne
Det kan helt sammenlignes med en prosess.
Merk: For enkelhets skyld, med mindre annet er spesifisert, regnes prosessen som hoveddelen nedenfor.
3.2 Formål
Ressurser som rektoren har tilgang til. Det kan være filer, kataloger, porter, enheter osv.
Merk: For enkelhets skyld, med mindre annet er spesifisert, regnes følgende dokumenter eller kataloger som objekter.
3.3 Politikk og regel
Det er vanligvis et stort antall filer og prosesser i systemet, og for å spare tid og overhead regulerer vi vanligvis bare visse prosesser selektivt.
Og hvilke prosesser som må reguleres og hvordan de skal kontrolleres, bestemmes av policy.
Det finnes flere regler i en policy. Noen regler kan aktiveres eller deaktiveres etter behov (heretter kalt boolske regler).
Reglene er modulære og utvidbare. Når man installerer en ny applikasjon, kan applikasjonen legge til regler ved å legge til nye moduler. Brukere kan også manuelt legge til eller trekke fra regler.
I CentOS 7-systemet finnes det tre sett med policyer, nemlig:
1. målrettet: Kontrollerer de fleste nettverkstjenesteprosesser. Dette er policyen som systemet bruker som standard (alle nedenfor brukes).
2. Minimum: Basert på målrettet er kun utvalgte nettverkstjenesteprosesser regulert. Generelt ikke.
3. MLS: Flernivå sikkerhetsbeskyttelse. Reguler alle prosesser. Dette er den strengeste policyen, og konfigurasjonen er veldig vanskelig. Generelt brukes det ikke med mindre det er svært høye sikkerhetskrav.
Policyer kan settes i /etc/selinux/config.
3.4 Sikkerhetskontekst
Sikkerhetskontekst er kjernen i SELinux.
Sikkerhetskontekst Jeg deler det inn i «prosesssikkerhetskontekst» og «dokumentsikkerhetskontekst».
En prosesssikkerhetskontekst tilsvarer vanligvis flere dokumentsikkerhetskontekster.
Bare når sikkerhetskonteksten til de to tilsvarer kan en prosess få tilgang til filen. Deres korrespondanse bestemmes av reglene i policyen.
Filsikkerhetskonteksten bestemmes av hvor filen ble opprettet og prosessen som opprettet den. Og systemet har et sett med standardverdier, og brukere kan også sette standardverdiene.
Det er viktig å merke seg at det å bare flytte filer ikke endrer sikkerhetskonteksten til filene dine.
Strukturen og betydningen av sikkerhetskonteksten
Sikkerhetskonteksten har fire felt, adskilt med kolon. Form som: system_u:object_r:admin_home_t:s0.
3.5 SELinux-arbeidsmodus
SELinux har tre driftsmoduser, nemlig:
1. håndheving: Håndhevet modus. Brudd på SELinux-reglene vil bli blokkert og loggført i loggene.
2. Tillatende: Toleransemodus. SELinux-regelbrudd loggføres kun i loggene. Generelt for feilsøking.
3. deaktivert: Slå av SELinux.
SELinux-arbeidsmodus kan settes i /etc/selinux/config.
Hvis du vil bytte fra deaktivert til håndhevende eller tillatende, må du starte systemet på nytt. Og omvendt.
Håndhevings- og tillatelsesmoduser kan raskt byttes med Setenforce 1|0-kommandoen.
Det er viktig å merke seg at hvis systemet har kjørt med SELinux slått av en stund, kan den første omstarten etter at SELinux er slått på være tregere. Fordi systemet må lage en sikker kontekst for filene på disken (jeg sa at jeg startet på nytt i omtrent 10 minutter og trodde den var død...... ）。
SELinux-logger må loggføres med hjelp av auditd.service, vennligst ikke deaktiver den.
3.6 SELinux-arbeidsflyt
Her er et sitat fra et bilde, uten mye forklaring.
Merk: Sikkerhetsteksten ovenfor refererer til sikkerhetskonteksten.
4. Grunnleggende SELinux-operasjoner
4.1 Spør sikkerhetskonteksten til en fil eller katalog
Grunnleggende bruk av kommando
ls -Z
Eksempler på bruk
Søk i sikkerhetskonteksten til /etc/hosts.
ls -Z /etc/hosts
Utførelsesresultater
-rw-r-r--. rotrot system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Spør i sikkerhetskonteksten til prosessen
Grunnleggende bruk av kommando
ps auxZ | grep -v grep | grep
Eksempler på bruk
Søk i sikkerhetskonteksten til Nginx-relaterte prosesser.
ps auxZ | grep -v grep | grep nginx
Utførelsesresultater
system_u:system_r:httpd_t:s0 root 7997 0.0 0.0 122784 2156 ? Ss 14:31 0:00 nginx: master process /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 7998 0.0 0.0 125332 7560 ? S 14:31 0:00 nginx: arbeiderprosess
4.3 Endre sikkerhetskonteksten manuelt for en fil eller katalog
Grunnleggende bruk av kommando
CHCON [...]
Alternativfunksjon -u Endre brukerfeltet i sikkerhetskonteksten -r Endre rollefeltet til sikkerhetskonteksten -t Endre typefeltet i sikkerhetskonteksten -l Endre nivåfeltet i sikkerhetskonteksten --referanse Endre sikkerhetskonteksten i samsvar med den angitte filen eller katalogen -R Rekursiv operasjon -h Endre sikkerhetskonteksten til den myke lenken (endre den tilsvarende filen til den myke lenken uten dette alternativet)
Eksempler på bruk
Endre sikkerhetskonteksten for testen til aaa_u:bbb_r:ccc_t:s0.
chcon -u aaa_u -r bbb_r -t ccc_t test
4.4 Tilbakestill sikkerhetskonteksten til en fil eller katalog til standardverdien
Grunnleggende bruk av kommando
RestoreCon [alternativer] [...]
Opsjonsfunksjon - V utskriftsoperasjonsprosedyre - R rekursiv operasjon
Eksempler på bruk
Etter at du har lagt til noen webfiler i mappen til Nginx-serveren din, sett riktig sikkerhetskontekst for disse nye filene.
restorecon -R /usr/share/nginx/html/
4.5 Søk etter boolske regler og deres status i systemet
Grunnleggende bruk av kommando
getsebool -a
Siden kommandoen spør enten alle regler eller bare én regel, spør den vanligvis alle regler først og filtrerer deretter med grep.
Eksempler på bruk
Søk i boolske regler relatert til httpd.
getsebool -a | grep httpd
Utførelsesresultater
httpd_anon_write --> av
httpd_builtin_scripting --> på
httpd_can_check_spam --> av
httpd_can_connect_ftp --> av
#以下省略
4.6 Bytte av en boolsk regel
Grunnleggende bruk av kommando
setsebool [alternativ]
Opsjonsfunksjon -P-restart trer fortsatt i kraft
Eksempler på bruk
Slå på httpd_anon_write regler.
setsebool -P httpd_anon_write på
4.7 Legg til en standard sikkerhetskontekst for en katalog
Grunnleggende bruk av kommando
semanage fcontext -a -t "(/.*)?"
Merk: Standard sikkerhetskontekst for en mappe eller fil kan vises ved å bruke kommandoen semanage fcontext -l sammen med grep-filtrering.
Eksempler på bruk
Etter at du har lagt til en ny sidekatalog /usr/share/nginx/html2 i Nginx, må du sette samme standard sikkerhetskontekst for den som for den opprinnelige katalogen.
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Legg til porter som er tillatt av visse typer prosesser
Grunnleggende bruk av kommando
semanage port -a -t -p
Merk: Portnumrene som er tillatt for ulike tjenestetyper kan vises ved å bruke kommandoen semanage port -l med grep-filtrering.
Eksempler på bruk
For Nginx må du bruke port 10080 for HTTP-tjenester.
Semanage Port -A -t http_port_t -p TCP 10080
5. SELinux-feilanalyse og oppløsning
5.1 Forståelse av SELinux-logger
Når SELinux er aktivert, regnes noe normal oppførsel for mange tjenester som et brudd (både i tittelen og i feilene nedenfor).
På dette tidspunktet må vi bruke SELinux-bruddslogger for å analysere og løse dem.
SELinux-bruddslogger lagres i /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(ingen) old-ses=4294967295 ses=25 res=1
type=USER_START msg=audit(1507898701.421:516): pid=8523 uid=0 auid=0 ses=25 subj=system_u:system_r:crond_t:s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_ keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" hostname=? ADDR=? terminal=cron res=suksess'
...
Filen består av mye innhold, og det er blandet med mange systemrevisjonslogger som ikke har noe med SELinux-feil å gjøre. Vi bruker sealert-verktøyet for å hjelpe med analysen (hvis prompten ikke finner kommandoen, installer setroubleshoot-pakken).
5.2 Analyser feil med sealert
Grunnleggende bruk av kommando
sealert -a /var/log/audit/audit.log
Etter å ha utført kommandoen, må systemet bruke litt tid på å analysere bruddene i loggene og levere en analyserapport. |
Publisert på 05.07.2019 11:25:50
|
|
|
|
Vert|
Publisert på 22.07.2021 17:17:58
|
