🥇Linux-säkerhetssystem

En av anledningarna till den stora framgången för Linux OS på inbyggda, mobila enheter och servrar är den relativt höga säkerheten i kärnan, tillhörande tjänster och applikationer. Men om man tittar noga på kärnarkitekturen i Linux, så går det inte att hitta någon specifik del som ansvarar för säkerheten i sig. Var gömmer sig då Linux säkerhetssystem och vad består det av?

Bakgrund till Linux Security Modules och SELinux

Security Enhanced Linux är en uppsättning regler och åtkomstmekanismer baserade på modeller för mandat- och rollbaserad åtkomst, för att skydda Linux-system mot potentiella hot och åtgärda brister i Discretionary Access Control (DAC) – det traditionella säkerhetssystemet i Unix. Projektet startades inom USA:s National Security Agency, och utvecklingen utfördes främst av kontraktörer från Secure Computing Corporation och MITRE, samt några forskningslaboratorier.

Linux Security Modules

Linus Torvalds gjorde en rad kommentarer om de nya utvecklingarna från NSA, så att de kunde inkluderas i huvudlinjen av Linux-kärnan. Han beskrev en generell miljö med en uppsättning interceptors för att hantera operationer med objekt och en uppsättning skyddade fält i kärnans datatyper för att lagra motsvarande attribut. Denna miljö kan sedan användas av laddningsbara kärnmoduler för att implementera önskad säkerhetsmodell. LSM integrerades fullständigt i Linux kärna v2.6 år 2003.

LSM-ramverket inkluderar skyddsfält i datatyper och anrop av interceptor-funktioner vid kritiska punkter i kärnkoden för att hantera dem och utföra åtkomstkontroll. Det lägger också till funktioner för registrering av säkerhetsmoduler. Gränssnittet /sys/kernel/security/lsm innehåller en lista över aktiva moduler i systemet. LSM-hooks lagras i listor som anropas i den ordning som anges i CONFIG_LSM. Det finns detaljerad dokumentation om hooks i headerfilen include/linux/lsm_hooks.h.

LSM-systemet möjliggjorde en fullständig integration av SELinux i samma version av den stabila Linux-kärnan v2.6. Strax efter blev SELinux en de facto-standard för den skyddade Linux-miljön och ingick i de mest populära distributionerna: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossarium SELinux

Identitet — Användaren SELinux är inte densamma som den vanliga Unix/Linux användar-ID:n, de kan samexistera på samma system men är helt olika i sin natur. Varje standard Linux-konto kan motsvara en eller flera i SELinux. IDENTITETEN för SELinux är en del av den övergripande säkerhetskontexten som bestämmer vilka domäner som kan betjänas och vilka som inte kan.
Domäner — I SELinux är en domän en körningskontext för ett subjekt, dvs. en process. Domänen bestämmer direkt åtkomsten som processen har. En domän är i huvudsak en lista över vad processer kan göra eller vilka åtgärder en process kan utföra med olika typer. Några exempel på domäner: sysadm_t för systemadministration och user_t, som är en vanlig icke-privilegierad användardomän. Init-systemet init körs i domänen init_t, medan processen named körs i domänen named_t.
Roller — Det som fungerar som en mellanhand mellan domäner och användare i SELinux. Roller definierar i vilka domäner en användare kan ingå och vilka typer av objekt han kan få åtkomst till. En sådan mekanism för åtkomstkontroll förhindrar hotet av att genomföra en höjning av privilegier. Roller är inskrivna i säkerhetsmodellen Role Based Access Control (RBAC) som används i SELinux.
Typer — Attributet för Type Enforcement-listan som tilldelas ett objekt och bestämmer vem som får åtkomst till det. Liknar definitionen av en domän, med den skillnaden att domänen tillämpas på processen medan typen tillämpas på objekt som kataloger, filer, sockets, etc.
Subjekt och objekt — Processer är subjekt och körs i en viss kontext, eller säkerhetsdomän. Resurser i operativsystemet: filer, kataloger, sockets etc., är objekt som tilldelas en viss typ, med andra ord — en sekretessnivå.
SELinux-policyer — För att skydda systemet använder SELinux en mängd olika policyer. SELinux-policyn definierar användares åtkomst till roller, roller till domäner och domäner till typer. Först godkänns en användare för att få en roll, sedan godkänns rollen för åtkomst till domäner. Slutligen kan en domän ha åtkomst till endast vissa typer av objekt.

LSM och arkitektur för SELinux

Trots namnet är LSM i grund och botten inte laddningsbara Linux-moduler. Precis som SELinux är den dock direkt integrerad i kärnan. Eventuella ändringar i LSM:s källkod kräver en ny kärnkompilering. Den relevanta alternativet måste vara aktiverat i kärninställningarna, annars kommer LSM-koden inte att aktiveras efter start. Men även i sådana fall kan den aktiveras med alternativet i operativsystemets bootloader.

LSM:s kontrollstack

LSM är försedd med hooks i huvudfunktionerna i kärnan som kan vara relevanta för kontroller. En av LSM:s huvudfunktioner är att de är organiserade i en stackprincip. Således utförs standardkontroller fortfarande och varje LSM-lager tillför endast ytterligare kontroll- och styrkomponenter. Det innebär att ett förbud inte kan rullas tillbaka. Detta visas på bilden, om resultatet av rutinmässiga DAC-kontroller är ett avslag, kommer det ens inte att nå LSM-haken.

SELinux har anammat Flask-säkerhetsarkitekturen från forskningsoperativsystemet Fluke, särskilt principen om minimiåtgärder. Kärnan i detta koncept, som namnet antyder, ligger i att ge användare eller processer endast de rättigheter som krävs för att utföra de avsedda åtgärderna. Denna princip realiseras genom tvångstypning av åtkomst, vilket innebär att behörighetskontrollen i SELinux baseras på en domän => typ-modell.

Genom tvångstypning av åtkomst har SELinux mycket mer betydande möjligheter för åtkomstkontroll än den traditionella DAC-modellen som används i Unix/Linux-system. Till exempel kan man begränsa numret på den nätverksport som ftp-servern kommer att lyssna på, tillåta skrivning och ändring av filer i en viss mapp, men inte deras borttagning.

De viktigaste komponenterna i SELinux är:

Policy Enforcement Server — Huvudmekanismen för åtkomstkontroll.
Databas för systemets säkerhetspolicyer.
Interaktion med LSM:s händelsefångare.
Selinuxfs — En pseudofil, liknande /proc, och monterad under /sys/fs/selinux. Fylls dynamiskt av Linux-kärnan under körning och innehåller filer med information om SELinux-status.
Access Vector Cache — Ett hjälpande mekanism för att öka prestanda.

Hur SELinux fungerar

Allt detta fungerar på följande sätt.

En viss subjekt, i termer av SELinux, utför en tillåten åtgärd på ett objekt efter DAC-kontroll, som visas i den övre bilden. Denna begäran om att utföra en åtgärd går till LSM-händelsefångaren.
Därifrån skickas begäran tillsammans med säkerhetskontexten för subjektet och objektet till SELinux Abstraction and Hook Logic-modulen, som ansvarar för interaktion med LSM.
Instansen för beslut om subjektets åtkomst till objektet är Policy Enforcement Server, och den får data från SELinux AnHL.
För att fatta beslut om åtkomst eller förbud, kontaktar Policy Enforcement Server cachen för de mest använda reglerna Access Vector Cache (AVC).
Om beslutet för den aktuella regeln inte finns i cachen, skickas begäran vidare till säkerhetspolisens databas.
Resultatet av sökningen från databasen och AVC returneras till Policy Enforcement Server.
Om den funna policyn överensstämmer med den begärda åtgärden, tillåts operationen. Annars förhindras operationen.

Hantera SELinux-inställningar

SELinux fungerar i ett av tre lägen:

Enforcing — Strikt efterlevnad av säkerhetspolicys.
Permissive — Överträdelser av begränsningar tillåts, och lämplig anteckning görs i loggen.
Disabled — Säkerhetspolicys är inte aktiva.

För att se vilket läge SELinux befinner sig i kan följande kommando användas.

[admin@server ~]$ getenforce
Permissive

Ändra läge till före omstart, till exempel sätta till enforcing, eller 1. Parameter permissive motsvarar den numeriska koden 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #samma sak

Läget kan också ändras 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=aktiverad # 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=targete

Skillnaden med setenfoce är att vid uppstart av operativsystemet sätts SELinux-läget enligt värdet av parametrarna i SELINUX-konfigurationsfilen. Dessutom träder ändringar av enforcing disabled endast i kraft genom att redigera filen /etc/selinux/config och efter omstart.

Visa en kort statusrapport:

[admin@server ~]$ sestatus

SELinux-status: aktiverad SELinuxfs-montering: /sys/fs/selinux SELinux root-katalog: /etc/selinux Laddad policy-namn: riktad Nuvarande läge: tillåtande Läge från konfigurationsfil: tvingande Policy MLS-status: aktiverad Policy deny_unknown-status: tillåten Max kernel policy-version: 31
För att visa 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 httpd

Jämfört med den vanliga utdata från ls -l finns det några ytterligare fält i följande format:

:::

Det sista fältet betecknar något som en sekretessklass och består av en kombination av två element:

s0 — betydelse, skrivs också som intervall lowlevel-highlevel
c0, c1… c1023 — kategori.

Ändra åtkomstkonfigurationer

Använd semodule för att ladda moduler för SELinux, lägga till och ta bort dem.

[admin@server ~]$ semodule -l |wc -l #lista över alla moduler
408
[admin@server ~]$ semodule -e abrt #enable - aktivera modul
[admin@server ~]$ semodule -d accountsd #disable - inaktivera modul
[admin@server ~]$ semodule -r avahi #remove - ta bort modul

Första kommandot semanage login kopplar SELinux-användare med operativsystems-användare, det andra skriver ut listan. Slutligen tar den sista kommandot med flaggan -r bort kopplingen av SELinux-användare till OS-konton. Förklaring av syntaxen för MLS/MCS Range finns i föregående avsnitt.

[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l

Inloggnamn SELinux Användare MLS/MCS Intervall Tjänst __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 user används för att hantera kopplingar mellan användare och roller för SELinux.

[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_u

Kommandoparametrar:

-a lägg till användarens rollkopplingspost;
-l lista kopplingar mellan användare och roller;
-d ta bort användarens rollkopplingspost;
-R lista roller kopplade till användaren;

Filer, portar och booleska värden

Varje SELinux-modul tillhandahåller en uppsättning filmärkningsregler, men det går också att lägga till egna regler vid behov. Till exempel vill vi ge webbservern åtkomst 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, medan det andra återställer, eller mer exakt, ställer in filtyperna enligt de aktuella reglerna.

På samma sätt är TCP/UDP-portar märkta på så sätt att endast motsvarande tjänster kan lyssna på dem. Till exempel, för att webbservern ska kunna lyssna på port 8080, måste man köra kommandot.

[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080

Ett betydande antal SELinux-moduler har parametrar som kan anta booleska värden. Den fullständiga listan över sådana parametrar kan ses med hjälp av getsebool -a. Booleska värden kan ändras 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

Praktikfall, få tillgång till Pgadmin-web gränssnittet.

Låt oss titta på ett exempel från praktiken. Vi har installerat pgadmin4-web på RHEL 7.6 för att administrera PostgreSQL-databaser. Vi genomgick en liten quest med konfigurationen av pg_hba.conf, postgresql.conf och config_local.py, ställde in rättigheterna på mapparna och installerade de saknade Python-modulerna via pip. Allt är klart, vi startar och får 500 Internal Server error.

Vi börjar med de typiska misstänkta, vi kontrollerar /var/log/httpd/error_log. Där finns några intressanta poster.

[timestamp] [core:notice] [pid 23689] SELinux-policy aktiverad; httpd kör som kontext system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Åtkomst nekad: '⁄var⁄lib⁄pgadmin' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] HINT : Du kan behöva ställa in behörigheterna manuellt på [timestamp] [wsgi:error] [pid 23690] ⁄var⁄lib⁄pgadmin för att tillåta apache att skriva till den.

Vid detta tillfälle kommer de flesta Linux-administratörer att känna en stark frestelse att köra setenforce 0 och så vara klara. Jag måste erkänna, första gången gjorde jag så. Detta är självklart också en lösning, men långt ifrån den bästa.

Trots de tunga strukturerna kan SELinux vara användarvänligt. Det räcker att installera paketet setroubleshoot och titta på systemloggen.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Observera att tjänsten auditd måste startas om på det här sättet, och inte med hjälp av systemctl, trots att systemd finns i OS:et. I systemloggen angives inte bara faktumet kring blockering, utan även orsaken och metoden för att övervinna förbudet..

Vi kör dessa kommandon: