1. Inledning
Security-Enhanced Linux (SELinux) är en Linux-kärnmodul och ett säkerhetsdelsystem inom Linux.
SELinux utvecklades främst av NSA. Linux-kärnor 2.6 och uppåt integrerar redan SELinux-moduler.
SELinux är mycket komplext och har mycket konceptuellt innehåll som är svårt att lära sig. Många Linux-systemadministratörer har stängt av SELinux eftersom de tycker det är besvärligt.
Om du kan bemästra SELinux och använda det rätt, tror jag att hela systemet i princip kan nå punkten att vara "oförstörbart" (kom alltid ihåg att det inte finns någon absolut säkerhet).
Att behärska grundkoncepten i SELinux samt enkla konfigurationsmetoder är en obligatorisk kurs för varje Linux-systemadministratör.
Denna artikel är baserad på CentOS 7.4.1708.
Den här artikeln är enbart en personlig lärande och utbyte, misstag är oundvikliga, endast för referens! Om du hittar ett misstag, vänligen påpeka det, tack så mycket!
2. SELinux roll och tillståndshanteringsmekanismen
2.1 SELinuxens roll
SELinuxs huvudfunktion är att minimera de resurser som kan nås av tjänsteprocesser i systemet (principen om minsta privilegium).
Föreställ dig att om en nätverkstjänst som körs som root har en 0day-sårbarhet, kan hackare utnyttja denna sårbarhet för att göra vad de vill på din server som root. Är det inte läskigt?
SELinux är här för att lösa detta problem.
2.2 DAC
I ett operativsystem som inte använder SELinux är faktorn som avgör om en resurs kan nås om resursen har behörigheter som motsvarande användare (läsa, skriva, köra).
Så länge processen som får tillgång till denna resurs uppfyller ovanstående villkor kan den nås.
Det mest fatala problemet är att root-användare inte omfattas av någon reglering, och alla resurser i systemet kan nås utan begränsningar.
Huvuddelen av denna behörighetshanteringsmekanism är användaren, även känd som autonom åtkomstkontroll (DAC).
2.3 MAC
I ett operativsystem som använder SELinux är de faktorer som avgör om en resurs kan nås inte bara ovanstående faktorer, utan också om varje typ av process har tillgång till en viss typ av resurs.
På så sätt är det, även om en process körs som root, nödvändigt att fastställa vilken typ av process och vilka typer av resurser som tillåts nås innan man bestämmer om åtkomst till en resurs ska tillåtas. Processens aktiva utrymme kan också komprimeras till ett minimum.
Även en tjänsteprocess som körs som root har vanligtvis bara tillgång till de resurser den behöver. Även om ett program är sårbart är omfattningen av påverkan begränsad till de resurser det får tillgång till. Säkerheten har ökat avsevärt.
Huvuddelen av denna behörighetshanteringsmekanism är processen, även känd som obligatorisk åtkomstkontroll (MAC).
MAC delas in i två sätt, det ena kallas Category Security (MCS)-läge och det andra Multi-Level Security (MLS)-läge.
Följande handlingar är i MCS-läge.
2.4 Jämförelse av DAC och MAC
Här är en bild för att illustrera.
Som du kan se, i DAC-läge, så länge motsvarande katalog har behörigheter från motsvarande användare, kan den nås. I MAC-läge är det också begränsat av det register som processer får komma åt.
3. Grundläggande koncept för SELinux
3.1 Ämne
Det kan helt och hållet likställas med en process.
Notera: För att underlätta förståelsen, om inget annat anges, betraktas processen som huvuddelen nedan.
3.2 Syfte
Resurser som rektorn har tillgång till. Det kan vara filer, kataloger, portar, enheter, osv.
Observera: För att underlätta förståelsen, om inget annat anges, betraktas följande dokument eller kataloger som objekt.
3.3 Policy & Regler
Det finns vanligtvis ett stort antal filer och processer i systemet, och för att spara tid och överhead reglerar vi vanligtvis bara vissa processer selektivt.
Och vilka processer som behöver regleras och hur de ska kontrolleras bestäms av policyn.
Det finns flera regler i en policy. Vissa regler kan aktiveras eller inaktiveras efter behov (hädanefter kallade boolesk regler).
Reglerna är modulära och utbyggbara. När en ny applikation installeras kan applikationen lägga till regler genom att lägga till nya moduler. Användare kan också manuellt lägga till eller subtrahera regler.
I CentOS 7-systemet finns tre uppsättningar policyer, nämligen:
1. riktad: Kontrollerar de flesta nätverksserviceprocesser. Detta är den policy som systemet använder som standard (alla nedanstående används).
2. Minimum: Baserat på målsatta regleras endast utvalda nätverksserviceprocesser. Generellt inte.
3. MLS: Flernivå-säkerhetsskydd. Reglera alla processer. Detta är den striktaste policyn, och konfigurationen är mycket svår. Generellt används den inte om det inte finns extremt höga säkerhetskrav.
Policys kan ställas in i /etc/selinx/config.
3.4 Säkerhetskontext
Säkerhetskontext är kärnan i SELinux.
Säkerhetskontext Jag delar in det i "processsäkerhetskontext" och "dokumentsäkerhetskontext".
En processsäkerhetskontext motsvarar vanligtvis flera dokumentsäkerhetskontexter.
Endast när säkerhetskontexten för de två motsvarar kan en process komma åt filen. Deras korrespondens bestäms av reglerna i policyn.
Filsäkerhetskontexten bestäms av var filen skapades och processen som skapade den. Och systemet har en uppsättning standardvärden, och användare kan också ställa in standardvärdena.
Det är viktigt att notera att det inte ändrar säkerhetskontexten för dina filer bara genom att flytta filer.
Strukturen och betydelsen av säkerhetskontexten
Säkerhetskontexten har fyra fält, separerade av kolon. Form som: system_u:object_r:admin_home_t:s0.
3.5 SELinux-arbetsläge
SELinux har tre driftssätt, nämligen:
1. upprätthållande: Påtvingat läge. Brott mot SELinux-reglerna kommer att blockeras och loggas i loggarna.
2. Tillåtande: Toleransläge. SELinux-regelbrott loggas endast i loggarna. Generellt för felsökning.
3. inaktiverat: Stäng av SELinux.
SELinux-arbetsläge kan ställas in i /etc/selinux/config.
Om du vill byta från inaktiverad till upprätthållande eller tillåtande måste du starta om systemet. Och tvärtom.
Enforce- och Permissive-lägen kan snabbt bytas med kommandot Setenforce 1|0.
Det är viktigt att notera att om systemet har körts med SELinux avstängt ett tag, kan den första omstarten efter att SELinux är påslagen gå långsammare. För systemet måste skapa en säker kontext för filerna på disken (jag sa att jag startade om i ungefär 10 minuter och trodde att den var död...... ）。
SELinux-loggar måste loggas med hjälp av auditd.service, vänligen inaktivera dem inte.
3.6 SELinux-arbetsflöde
Här är ett citat från en bild, utan mycket förklaring.
Notera: Säkerhetstexten ovan avser säkerhetskontexten.
4. Grundläggande SELinux-operationer
4.1 Sök säkerhetskontexten för en fil eller katalog
Grundläggande användning av kommando
ls -Z
Exempel på användning
Sök i säkerhetskontexten för /etc/hosts.
ls -Z /etc/hosts
Genomföranderesultat
-rw-r-r--. rotrot system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Fråga i processens säkerhetskontext
Grundläggande användning av kommando
ps auxZ | grep -v grep | grep
Exempel på användning
Sök i säkerhetskontexten för Nginx-relaterade processer.
ps auxZ | grep -v grep | grep nginx
Genomföranderesultat
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: arbetsprocess
4.3 Manuellt ändra säkerhetskontexten för en fil eller katalog
Grundläggande användning av kommando
CHCON [...]
Alternativfunktion -u Modifiera användarfältet i säkerhetskontexten -r Ändra rollfältet för säkerhetskontexten -t Ändra typfältet för säkerhetskontexten -l Ändra nivåfältet för säkerhetskontexten --referens Modifiera säkerhetskontexten i enlighet med den angivna filen eller katalogen -R Rekursiv operation -h Modifiera säkerhetskontexten för mjuklänken (ändra motsvarande fil för mjuklänken utan detta alternativ)
Exempel på användning
Ändra säkerhetskontexten för testet till aaa_u:bbb_r:ccc_t:s0.
CHCON -U aaa_u -R bbb_r -T ccc_t test
4.4 Återställ säkerhetskontexten för en fil eller katalog till dess standardvärde
Grundläggande användning av kommando
restorecon [alternativ] [...]
Optionsfunktion - V utskriftsoperation propuder - R rekursiv operation
Exempel på användning
Efter att du lagt till några webbfiler i katalogen på din Nginx-server, ställ in rätt säkerhetskontext för dessa nya filer.
restorecon -R /usr/share/nginx/html/
4.5 Fråga Booleska regler och deras status i systemet
Grundläggande användning av kommando
getsebool -a
Eftersom kommandot frågar antingen alla regler eller bara en regel, frågar det vanligtvis alla regler först och filtrerar sedan med grep.
Exempel på användning
Sök efter booleska regler relaterade till httpd.
getsebool -a | grep httpd
Genomföranderesultat
httpd_anon_write -->
httpd_builtin_scripting -->
httpd_can_check_spam --> iväg
httpd_can_connect_ftp --> av
#以下省略
4.6 Byta av en boolesk regel
Grundläggande användning av kommando
setsebool [alternativ]
Optionsfunktionen -P omstart gäller fortfarande
Exempel på användning
Slå på httpd_anon_write regler.
setsebool -P httpd_anon_write on
4.7 Lägg till en standardsäkerhetskontext för en katalog
Grundläggande användning av kommando
semanage fcontext -a -t "(/.*)?"
Observera: Standardsäkerhetskontexten för en katalog eller fil kan visas genom att använda kommandot semanage fcontext -l i kombination med grep-filtrering.
Exempel på användning
Efter att du lagt till en ny webbplatskatalog /usr/share/nginx/html2 i Nginx behöver du ställa in samma standardsäkerhetskontext för den som för den ursprungliga katalogen.
Semanage Fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Lägg till portar som tillåts av vissa typer av processer
Grundläggande användning av kommando
semanage port -a -t -p
Observera: Portnumren som tillåts för olika tjänstetyper kan visas genom att använda kommandot semanage port -l med grep-filtrering.
Exempel på användning
För Nginx behöver du använda port 10080 för HTTP-tjänster.
Semanage Port -A -T http_port_t -P TCP 10080
5. SELinux-felanalys och lösning
5.1 Förståelse av SELinux-loggar
När SELinux är aktiverat betraktas vissa normala beteenden hos många tjänster som ett brott (både i titeln och i felmeddelandena nedan).
Just nu behöver vi använda SELinux-överträdelseloggar för att analysera och lösa dem.
SELinux-överträdelseloggar sparas 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=framgång'
...
Filen är mycket innehåll, och den blandas med många systemgranskningsloggar som inte har något med SELinux-fel att göra. Vi använder sealert-verktyget för att hjälpa till med analysen (om prompten inte hittar kommandot, installera setroubleshoot-paketet).
5.2 Analysera fel med tätning
Grundläggande användning av kommando
sealert -a /var/log/audit/audit.log
Efter att kommandot har exekverats behöver systemet ta sig tid att analysera överträdelserna i loggarna och tillhandahålla en analysrapport. |
Publicerad på 2019-07-05 11:25:50
|
|
|
|
Hyresvärd|
Publicerad på 2021-07-22 17:17:58
|
