🥇Beskyttelsessystemer til Linux

En af grundene til den enorme succes for Linux OS på indlejrede, mobile enheder og servere er den relativt høje grad af sikkerhed i kernen, tilhørende tjenester og applikationer. Men hvis man ser nøje på arkitekturen af Linux-kernen, kan man ikke finde en sektion, der specifikt omhandler sikkerhed. Hvor gemmer sikkerhedssubsystemet i Linux sig, og hvad består det af?

Forhistorien bag Linux Security Modules og SELinux

Security Enhanced Linux er et regelsæt og adgangsmekanismer, baseret på modeller for mandatorisk og rollebaseret adgang, til beskyttelse af Linux-systemer mod potentielle trusler og rettelse af mangler i Discretionary Access Control (DAC) — den traditionelle sikkerhedssystem for Unix. Projektet blev initieret af det amerikanske National Security Agency, og udviklingen blev primært udført af kontraktører fra Secure Computing Corporation og MITRE, samt flere forskningslaboratorier.

Linux Security Modules

Linus Torvalds kom med en række bemærkninger om de nye udviklinger fra NSA, så de kunne inkluderes i den primære gren af Linux-kernen. Han beskrev et generelt miljø med et sæt interceptorer til håndtering af operationer med objekter og et sæt beskyttelsesfelter i kernens datastrukturer til opbevaring af de relevante attributter. Dette miljø kan derefter anvendes af indlæste kernelmoduler til at implementere enhver ønsket sikkerhedsmodel. LSM blev fuldt integreret i Linux-kernen v2.6 i 2003.

LSM-rammen inkluderer beskyttelsesfelter i datastrukturer og funktionsopkald for interception i kritiske punkter af koden i kernen for at administrere dem og udføre adgangskontrol. Den tilføjer også funktioner til registrering af sikkerhedsmoduler. Interface /sys/kernel/security/lsm indeholder en liste over aktive moduler i systemet. LSM-hooks opbevares i lister, der kaldes i den rækkefølge, der er angivet i CONFIG_LSM. Detaljeret dokumentation for hooks er inkluderet i header-filen include/linux/lsm_hooks.h.

LSM-subsystemet gjorde det muligt at afslutte den fuldgyldige integration af SELinux med den samme version af den stabile Linux-kernen v2.6. Lige straks blev SELinux standarden de facto for det sikrede miljø i Linux og indgik i de mest populære distributioner: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossar for SELinux

Identitet — SELinux-brugeren er ikke det samme som den velkendte Unix-/Linux-bruger-id; de kan sameksistere på det samme system, men er i sin essens helt forskellige. Hver standard Linux-konto kan svare til en eller flere i SELinux. SELinux-identiteten er en integreret del af den overordnede sikkerhedskontekst, der bestemmer, hvilke domæner man kan få adgang til, og hvilke man ikke kan.
Domæner — I SELinux er et domæne udførelseskonteksten for et subjekt, dvs. en proces. Domænet bestemmer direkte den adgang, som processen har. Et domæne er stort set en liste over, hvad processer kan gøre, eller hvilke handlinger en proces kan udføre med forskellige typer. Nogle eksempler på domæner inkluderer sysadm_t til systemadministration og user_t, som er det almindelige ikke-privilegerede domæne for brugere. Init-systemet kører i domænet init_t, mens processen named kører i domænet named_t.
Roller — Det, der fungerer som en mægler mellem domæner og brugere i SELinux. Roller definerer, hvilke domæner en bruger kan tilhøre, og hvilke typer objekter vedkommende kan få adgang til. En sådan adgangsbegrænsningsmekanisme forhindrer trusler om privilegieforskydning. Roller er indskrevet i modellen for sikkerhed baseret på rolleadgangskontrol (RBAC), der anvendes i SELinux.
Typer — Attributten i Type Enforcement-listen, der tildeles et objekt og definerer, hvem der får adgang til det. Det ligner definitionen af et domæne, bortset fra at domænet anvendes på en proces, mens typen anvendes på objekter som mapper, filer, sockets osv.
Subjekter og objekter — Processer er subjekter og kører i en bestemt kontekst, eller sikkerhedsdomaene. Ressourcerne i operativsystemet: filer, mapper, sockets osv., er objekter, der tildeles en bestemt type, eller med andre ord — et sikkerhedsniveau.
SELinux-politikker — For at beskytte systemet anvender SELinux forskellige politikker. SELinux-politikken bestemmer brugernes adgang til roller, rollerne til domæner og domænerne til typer. Først autoriseres brugeren til at få en rolle, derefter autoriseres rollen til at få adgang til domæner. Endelig kan et domæne kun få adgang til nogle typer objekter.

LSM og arkitekturen af SELinux

På trods af navnet er LSM i princippet ikke indlæselige moduler til Linux. Men ligesom SELinux er det direkte integreret i kernen. Enhver ændring af kildekoden til LSM kræver en ny kompilering af kernen. Den relevante indstilling skal aktiveres i kerneindstillingerne, ellers bliver LSM-koden ikke aktiveret efter opstart. Men selv i dette tilfælde kan det aktiveres ved hjælp af OS-lasterindstillingen.

LSM-kontrolstakken

LSM er udstyret med hooks i de vigtigste kernefunktioner, som kan være relevante for kontroller. En af hovedfunktionerne ved LSM er, at de er struktureret i et lag. Dermed udføres standardkontroller stadig, og hvert lag af LSM tilføjer blot yderligere kontrol- og overvågningselementer. Dette betyder, at forbud ikke kan tilbagekaldes. Det er vist i figuren; hvis resultatet af de rutinemæssige DAC-kontroller fører til afvisning, vil det ikke engang nå til LSM-hooks.

SELinux har overtaget Flask-sikkerhedsarkitekturen fra forskningsoperativsystemet Fluke, især princippet om mindst privilegier. Essensen af dette koncept, som antydet af deres navn, er at give en bruger eller en proces kun de rettigheder, der er nødvendige for at udføre de påtænkte handlinger. Dette princip implementeres gennem tvungen adgangs-typificering, således at kontrol af adgang i SELinux er baseret på modellen domæne => type.

Takket være tvungen adgangs-typificering har SELinux meget mere betydelige muligheder for at begrænse adgangen sammenlignet med den traditionelle DAC-model, der anvendes i Unix/Linux. For eksempel kan man begrænse nummeret på den netværksport, som FTP-serveren lytter på, tillade skrivning og ændringer af filer i en bestemt mappe, men ikke deres sletning.

De vigtigste komponenter i SELinux er:

Policy Enforcement Server — Den primære mekanisme til organisering af adgangskontrol.
Database for systemets sikkerhedspolitikker.
Interaktion med LSM-begivenhedsfanger.
Selinuxfs — Et pseudo-FS, der er ligesom /proc og monteret i /sys/fs/selinux. Det fyldes dynamisk af Linux-kernen under kørsel og indeholder filer, der indeholder oplysninger om SELinux-status.
Access Vector Cache — En hjælpmekanisme til at forbedre ydeevnen.

SELinux's funktionsskema

Alt dette fungerer på følgende måde.

En enhed, i SELinux-terminologi, udfører en tilladt handling på et objekt efter DAC-kontrol, som vist på det øverste billede. Denne anmodning om at udføre en handling sendes til LSM-begivenhedssamleren.
Derfra sendes anmodningen sammen med sikkerhedskonteksten for subjektet og objektet til SELinux Abstraction and Hook Logic-modulet, som er ansvarligt for interaktionen med LSM.
Instansen, som træffer beslutning om subjektets adgang til objektet, er Policy Enforcement Server, og den modtager data fra SELinux AnHL.
For at træffe en beslutning om adgang eller afvisning henvender Policy Enforcement Server sig til cache-systemet for de mest anvendte regler, Access Vector Cache (AVC).
Hvis beslutningen for den relevante regel ikke findes i cachen, overføres anmodningen til databasen for sikkerhedspolitikker.
Resultatet af søgningen fra databasen og AVC returneres til Policy Enforcement Server.
Hvis den fundne politik er i overensstemmelse med den anmodede handling, tillades operationen. Ellers nægtes operationen.

Håndtering af SELinux-indstillinger

SELinux fungerer i en af tre tilstande:

Enforcing — Streng overholdelse af sikkerhedspolitikker.
Permissive — Overtrædelser af begrænsninger tillades, og der laves en bemærkning i loggen.
Disabled — Sikkerhedspolitikkerne er ikke aktive.

For at se i hvilken tilstand SELinux befinder sig, kan følgende kommando bruges.

[admin@server ~]$ getenforce
Permissive

Ændring af tilstanden indtil genstart, for eksempel ved at sætte den til enforcing, eller 1. Talværdien for permissive er 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #det samme

Tilstanden kan også ændres ved at redigere 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=aktiv # 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

Forskellen med setenfoce er, at ved opstart af operativsystemet vil SELinux-tilstanden sættes i overensstemmelse med værdien af SELINUX-parameteren i konfigurationsfilen. Desuden træder ændringer fra enforcing disabled kun i kraft gennem redigering af filen /etc/selinux/config og efter genstart.

Vis en kort statusrapport:

[admin@server ~]$ sestatus

SELinux-status: aktiveret SELinuxfs-mount: /sys/fs/selinux SELinux-rodkatalog: /etc/selinux Indlæst politik navn: målrettet Nuværende tilstand: tilladende Tilstand fra konfigurationsfil: håndhævende Politik MLS-status: aktiveret Politik deny_unknown-status: tilladt Maksimal kernel politik version: 31
For at se SELinux-attributter bruger nogle standard værktøjer parameteren -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

Sammenlignet med den almindelige ls -l udgang er der her flere ekstra felter i følgende format:

:::

Det sidste felt angiver noget i stil med en sikkerhedsklassificering og består af en kombination af to elementer:

s0 — betydning, også skrevet som interval lowlevel-highlevel
c0, c1… c1023 — kategori.

Ændring af adgangskonfigurationer

Brug semodule til at indlæse SELinux-moduler, tilføje og fjerne dem.

[admin@server ~]$ semodule -l |wc -l #liste over alle moduler
408
[admin@server ~]$ semodule -e abrt #aktivere - aktivér modulet
[admin@server ~]$ semodule -d accountsd #deaktivere - fjern modulet
[admin@server ~]$ semodule -r avahi #fjern - fjern modulet

Den første kommando semanage login binder en SELinux-bruger til en operativsystembruger, den anden viser listen. Endelig fjerner den sidste kommando med flagget -r bindingen af SELinux-brugere til operativsystemkonti. Forklaringen af syntaksen for værdierne MLS/MCS Range findes i det foregående afsnit.

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

Login-navn SELinux-bruger MLS/MCS-område Tjeneste __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
Kommandoen semanage user bruges til at administrere bindelser mellem brugere og roller i SELinux.

[admin@server ~]$ semanage user -l
                Labeling   MLS/       MLS/                          
SELinux-bruger    Prefix     MCS Level  MCS Range             SELinux Roller
guest_u         bruger       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          bruger       s0         s0                    user_r
xguest_u        bruger       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u

Kommandoens parametre:

-a tilføje en brugeroptegnelse for rollebindelser;
-l liste over bruger- og rollebindelser;
-d fjerne en brugeroptegnelse for rollebindelser;
-R liste over roller knyttet til brugeren;

Filer, porte og boolske værdier

Hver SELinux-modul tilbyder et sæt filmærkningsregler, men man kan også tilføje egne regler om nødvendigt. For eksempel ønsker vi at give webserveren adgangsrettigheder til mappen /srv/www.

[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/

Den første kommando registrerer nye mærkningsregler, mens den anden nulstiller, eller rettere, indstiller filtyper i overensstemmelse med de aktuelle regler.

Tilsvarende er TCP/UDP porte markeret, så kun de tilsvarende tjenester kan lytte til dem. For eksempel, for at webserveren kan lytte til port 8080, skal du udføre kommandoen.

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

Et betydeligt antal SELinux-moduler har parametre, der kan tage booleske værdier. Den komplette liste over sådanne parametre kan ses med getsebool -a. Du kan ændre de booleske værdier 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

Praktikum, få adgang til Pgadmin-web-grænsefladen

Lad os se på et praktisk eksempel, vi har installeret pgadmin4-web på RHEL 7.6 til administration af PostgreSQL-databaser. Vi har gennemgået en lille quest med konfiguration af pg_hba.conf, postgresql.conf og config_local.py, sat rettigheder på mapperne, installeret de manglende Python-moduler fra pip. Alt er klar, vi starter og får 500 Internal Server error.

Vi starter med de typiske mistænkte og tjekker /var/log/httpd/error_log. Der er nogle interessante poster.

[timestamp] [core:notice] [pid 23689] SELinux-politik aktiveret; httpd kører som kontekst system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Adgang nægtet: '\/var\/lib\/pgadmin' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] HINT : Du skal muligvis manuelt indstille tilladelserne på [timestamp] [wsgi:error] [pid 23690] \/var\/lib\/pgadmin for at tillade apache at skrive til den.

På dette tidspunkt vil de fleste Linux-administratorer have en vedholdende fristelse til at køre setenforce 0, og så var det sådan set det. For at være ærlig, det gjorde jeg også første gang. Det er selvfølgelig også en løsning, men bestemt ikke den bedste.

På trods af kompleksiteten kan SELinux være brugervenligt. Det er tilstrækkeligt at installere pakken setroubleshoot og gennemgå systemloggen.

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

Bemærk, at tjenesten auditd skal genstartes på denne måde, og ikke med systemctl, på trods af tilstedeværelsen af systemd i OS. I systemloggen vil det ikke kun angive faktumet om blokeringen, men også årsagen og metoden til at omgå forbuddet.

Udfør disse kommandoer: