En av anledningarna till den enorma framgången för Linux OS på inbäddade, mobila enheter och servrar är den ganska höga graden av säkerhet för kärnan, relaterade tjänster och applikationer. Men om till Linux-kärnans arkitektur, då är det omöjligt att hitta en kvadrat som ansvarar för säkerheten i den. Var gömmer sig Linux-säkerhetsundersystemet och vad består det av?
Bakgrund om Linux Security Modules och SELinux
Security Enhanced Linux är en uppsättning regler och åtkomstmekanismer baserade på obligatoriska och rollbaserade åtkomstmodeller för att skydda Linux-system från potentiella hot och korrigera bristerna i Discretionary Access Control (DAC), det traditionella Unix-säkerhetssystemet. Projektet har sitt ursprung i USA:s nationella säkerhetsbyrå och utvecklades direkt av entreprenörerna Secure Computing Corporation och MITER, samt ett antal forskningslaboratorier.
Linux säkerhetsmoduler
Linus Torvalds gjorde ett antal kommentarer om nya NSA-utvecklingar så att de kunde inkluderas i Linux-kärnan. Han beskrev en allmän miljö, med en uppsättning interceptorer för att styra operationer med objekt och en uppsättning av vissa skyddande fält i kärndatastrukturer för att lagra motsvarande attribut. Denna miljö kan sedan användas av laddningsbara kärnmoduler för att implementera vilken säkerhetsmodell som helst. LSM gick helt in i Linux-kärnan v2.6 2003.
LSM-ramverket inkluderar skyddsfält i datastrukturer och anrop till avlyssningsfunktioner vid kritiska punkter i kärnkoden för att manipulera dem och utföra åtkomstkontroll. Det lägger också till funktionalitet för att registrera säkerhetsmoduler. Gränssnittet /sys/kernel/security/lsm innehåller en lista över aktiva moduler i systemet. LSM-krokar lagras i listor som anropas i den ordning som anges i CONFIG_LSM. Detaljerad dokumentation om hooks ingår i rubrikfilen include/linux/lsm_hooks.h.
LSM-undersystemet gjorde det möjligt att slutföra den fullständiga integrationen av SELinux med samma version av den stabila Linux-kärnan v2.6. Nästan omedelbart blev SELinux de facto-standarden för en säker Linux-miljö och ingick i de mest populära distributionerna: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.
SELinux ordlista
- identitet — SELinux-användaren är inte densamma som det vanliga Unix/Linux-användar-id:t, de kan samexistera på samma system, men är helt olika i huvudsak. Varje standard Linux-konto kan motsvara ett eller flera i SELinux. SELinux-identiteten är en del av den övergripande säkerhetskontexten, som avgör vilka domäner du kan och inte kan gå med i.
- domäner - I SELinux är en domän exekveringskontexten för ett ämne, det vill säga en process. Domänen bestämmer direkt vilken åtkomst en process har. En domän är i grunden en lista över vad processer kan göra eller vad en process kan göra med olika typer. Några exempel på domäner är sysadm_t för systemadministration och user_t som är en normal icke-privilegierad användardomän. Init-systemet körs i init_t-domänen, och den namngivna processen körs i named_t-domänen.
- roll — Det som fungerar som en mellanhand mellan domäner och SELinux-användare. Roller avgör vilka domäner en användare kan tillhöra och vilka typer av objekt de har åtkomst till. Denna åtkomstkontrollmekanism förhindrar hotet om attacker med eskalering av rättigheter. Roller skrivs in i säkerhetsmodellen Role Based Access Control (RBAC) som används i SELinux.
- Typer — Ett Type Enforcement-listattribut som tilldelas ett objekt och bestämmer vem som kan komma åt det. Liknar domändefinitionen, förutom att domänen gäller för en process, och typen gäller för objekt som kataloger, filer, sockets, etc.
- Ämnen och föremål – Processer är ämnen och körs i ett specifikt sammanhang, eller säkerhetsdomän. Operativsystemresurser: filer, kataloger, sockets etc. är objekt som tilldelas en viss typ, med andra ord en integritetsnivå.
- SELinux policyer — SELinux använder en mängd olika policyer för att skydda systemet. SELinux-policyn definierar användarnas åtkomst till roller, roller till domäner och domäner till typer. Först är användaren auktoriserad att erhålla en roll, sedan är rollen behörig att få åtkomst till domäner. Slutligen kan en domän bara ha tillgång till vissa typer av objekt.
LSM och SELinux arkitektur
Trots namnet är LSM i allmänhet inte laddningsbara Linux-moduler. Men liksom SELinux är den direkt integrerad i kärnan. Varje ändring av LSM-källkoden kräver en ny kärnkompilering. Motsvarande alternativ måste vara aktiverat i kärninställningarna, annars kommer inte LSM-koden att aktiveras efter uppstart. Men även i det här fallet kan det aktiveras av OS bootloader-alternativet.
LSM check stack
LSM är utrustad med krokar i kärnkärnfunktioner som kan vara aktuella för kontroller. En av huvuddragen hos LSM är att de är staplade. Således utförs standardkontrollerna fortfarande, och varje lager av LSM lägger bara till ytterligare kontroller och kontroller. Det innebär att förbudet inte kan rullas tillbaka. Detta visas i figuren; om resultatet av rutinmässiga DAC-kontroller är ett misslyckande, kommer saken inte ens att nå LSM-krokarna.
SELinux använder Flask-säkerhetsarkitekturen för Flukes forskningsoperativsystem, särskilt principen om minsta privilegium. Kärnan i detta koncept, som namnet antyder, är att ge användaren eller bearbeta endast de rättigheter som är nödvändiga för att utföra de avsedda åtgärderna. Denna princip implementeras med tvångsinmatning, så åtkomstkontroll i SELinux är baserad på domänen => typmodellen.
Tack vare forcerad åtkomstskrivning har SELinux mycket större åtkomstkontrollmöjligheter än den traditionella DAC-modellen som används i Unix/Linux operativsystem. Du kan till exempel begränsa nätverksportnumret som ftp-servern ska ansluta till, tillåta att skriva och ändra filer i en viss mapp, men inte ta bort dem.
Huvudkomponenterna i SELinux är:
- Policy Enforcement Server — Huvudmekanismen för att organisera tillträdeskontroll.
- Databas för systemsäkerhetspolicy.
- Interaktion med LSM-händelseinterceptor.
- Selinuxfs - Pseudo-FS, samma som /proc och monterad i /sys/fs/selinux. Dynamiskt fylld av Linux-kärnan vid körning och innehåller filer som innehåller SELinux-statusinformation.
- Få åtkomst till vektorcache — En hjälpmekanism för att öka produktiviteten.
Hur SELinux fungerar
Det hela fungerar så här.
- Ett visst ämne, i SELinux-termer, utför en tillåten åtgärd på ett objekt efter en DAC-kontroll, som visas på den översta bilden. Denna begäran att utföra en operation går till LSM-händelseinterceptorn.
- Därifrån skickas begäran, tillsammans med ämnes- och objektsäkerhetskontexten, till modulen SELinux Abstraction and Hook Logic, som är ansvarig för interaktion med LSM.
- Beslutsmyndigheten för en subjekts åtkomst till ett objekt är Policy Enforcement Server och den tar emot data från SELinux AnHL.
- För att fatta beslut om åtkomst eller nekande, vänder sig Policy Enforcement Server till undersystemet Access Vector Cache (AVC) för de mest använda reglerna.
- Om en lösning för motsvarande regel inte hittas i cachen, skickas begäran vidare till säkerhetspolicydatabasen.
- Sökresultatet från databasen och AVC returneras till Policy Enforcement Server.
- Om den hittade policyn matchar den begärda åtgärden är åtgärden tillåten. Annars är operationen förbjuden.
Hantera SELinux-inställningar
SELinux fungerar i ett av tre lägen:
- Upprätthållande - Strikt efterlevnad av säkerhetspolicyer.
- Tillåtande - Brott mot restriktioner är tillåtet; motsvarande anteckning görs i journalen.
- Inaktiverad – Säkerhetspolicyer är inte i kraft.
Du kan se vilket läge SELinux är i med följande kommando.
[admin@server ~]$ getenforce
PermissiveÄndra läget före omstart, till exempel, ställa in det på verkställande, eller 1. Den tillåtande parametern motsvarar den numeriska koden 0.
[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое
Du kan också ändra läget genom att redigera filen:
[admin@server ~]$ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=mål
Skillnaden med setenfoce är att när operativsystemet startar kommer SELinux-läget att ställas in i enlighet med värdet på SELINUX-parametern i konfigurationsfilen. Dessutom träder ändringar för att upprätthålla <=> inaktiverade endast i kraft genom att redigera filen /etc/selinux/config och efter en omstart.
Se en kort statusrapport:
[admin@server ~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
För att se SELinux-attribut använder vissa standardverktyg parametern -Z.
[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL PID TTY TIME CMD
system_u:system_r:httpd_t:s0 2914 ? 00:00:04 httpd
system_u:system_r:httpd_t:s0 2915 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 2916 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 2917 ? 00:00:00 httpd
...
system_u:system_r:httpd_t:s0 2918 ? 00:00:00 httpdJämfört med den normala utmatningen av ls -l, finns det flera ytterligare fält i följande format:
<user>:<role>:<type>:<level>
Det sista fältet betecknar något som en säkerhetsklassificering och består av en kombination av två element:
- s0 - signifikans, även skrivet som lågnivå-högnivåintervall
- c0, c1… c1023 - kategori.
Ändra åtkomstkonfiguration
Använd semodule för att ladda, lägga till och ta bort SELinux-moduler.
[admin@server ~]$ semodule -l |wc -l #список всех модулей
408
[admin@server ~]$ semodule -e abrt #enable - активировать модуль
[admin@server ~]$ semodule -d accountsd #disable - отключить модуль
[admin@server ~]$ semodule -r avahi #remove - удалить модульFörsta laget semanage inloggning ansluter SELinux-användaren till operativsystemanvändaren, den andra visar en lista. Slutligen tar det sista kommandot med -r-växeln bort mappningen av SELinux-användare till OS-konton. En förklaring av syntaxen för MLS/MCS Range-värden finns i föregående avsnitt.
[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
[admin@server ~]$ semanage login -d karol
Team semanage användare används för att hantera mappningar mellan SELinux-användare och roller.
[admin@server ~]$ semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r
...
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_uKommandoparametrar:
- -a lägga till anpassad rollmappningspost;
- -l lista över matchande användare och roller;
- -d ta bort användarrollmappningsposten;
- -R lista över roller kopplade till användaren;
Filer, portar och booleska värden
Varje SELinux-modul tillhandahåller en uppsättning filtaggningsregler, men du kan också lägga till dina egna regler om det behövs. Till exempel vill vi att webbservern ska ha åtkomsträttigheter till mappen /srv/www.
[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/Det första kommandot registrerar nya märkningsregler och det andra återställer, eller snarare sätter, filtyperna i enlighet med de nuvarande reglerna.
På samma sätt är TCP/UDP-portar märkta på ett sådant sätt att endast lämpliga tjänster kan lyssna på dem. Till exempel, för att webbservern ska lyssna på port 8080, måste du köra kommandot.
[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080Ett betydande antal SELinux-moduler har parametrar som kan ta booleska värden. Hela listan över sådana parametrar kan ses med getsebool -a. Du kan ändra booleska värden med setsebool.
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_homedirs --> off
Workshop, få tillgång till Pgadmin-webbgränssnittet
Låt oss titta på ett praktiskt exempel: vi installerade pgadmin7.6-web på RHEL 4 för att administrera PostgreSQL-databasen. Vi gick lite med inställningarna för pg_hba.conf, postgresql.conf och config_local.py, ställ in mappbehörigheter, installerade de saknade Python-modulerna från pip. Allt är klart, vi lanserar och tar emot 500 Internt serverfel.
Vi börjar med de typiska misstänkta och kollar /var/log/httpd/error_log. Det finns några intressanta poster där.
[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
...
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.
Vid det här laget kommer de flesta Linux-administratörer att vara starkt frestade att köra setencorce 0, och det kommer att vara slutet på det. Ärligt talat, jag gjorde precis det första gången. Detta är förstås också en utväg, men långt ifrån den bästa.
Trots den krångliga designen kan SELinux vara användarvänlig. Installera bara setroubleshoot-paketet och se systemloggen.
[admin@server ~]$ yum install setroubleshoot
[admin@server ~]$ journalctl -b -0
[admin@server ~]$ service restart auditd
Observera att den granskade tjänsten måste startas om på detta sätt och inte använda systemctl, trots närvaron av systemd i operativsystemet. I systemloggen kommer att anges inte bara faktumet att blockera, utan också orsaken och sätt att övervinna förbudet.
Vi kör dessa kommandon:
[admin@server ~]$ setsebool -P httpd_can_network_connect 1
[admin@server ~]$ setsebool -P httpd_can_network_connect_db 1
Vi kontrollerar tillgången till pgadmin4-webbsidan, allt fungerar.
Källa: will.com