🥇Beskyttelsessystemer til Linux

En af årsagerne til den enorme succes for Linux OS på indbyggede, mobile enheder og servere er den relativt høje grad af sikkerhed i kernen, de tilhørende tjenester og applikationer. Men hvis man ser nærmere på arkitekturen af Linux-kernen, kan man ikke finde en specifik komponent, der er ansvarlig for sikkerhed som sådan. Hvor gemmer Linux’ sikkerhedssubsystem sig og hvad består det af?

Baggrunden for Linux Security Modules og SELinux

Security Enhanced Linux er en samling af regler og adgangsmekanismer baseret på modeller for mandatorisk og rollebaseret adgang, som beskytter Linux-systemer mod potentielle trusler og retter op på manglerne i Discretionary Access Control (DAC) - det traditionelle sikkerhedssystem i Unix. Projektet blev udviklet af det amerikanske National Security Agency, primært under udvikling af entreprenører som Secure Computing Corporation og MITRE samt forskellige forskningslaboratorier.

Linux Security Modules

Linus Torvalds kom med en række bemærkninger om nye udviklinger fra NSA, så de kunne inkluderes i hovedgrenen af Linux-kernen. Han beskrev et samlet miljø med et sæt interceptorer til styring af operationer med objekter og et sæt beskyttelsesfelter i kerne-data-strukturer for at gemme de relevante attributter. Dette miljø kan derefter bruges af indlæste kerne-moduler til at implementere enhver ønsket sikkerhedsmodel. LSM blev fuldt integreret i Linux-kernen v2.6 i 2003.

LSM-rammen inkluderer beskyttelsesfelter i data-strukturer og funktionens interceptionskald i kritiske punkter i kernelens kode 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-hukkerne gemmes 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-sousystemet har gjort det muligt at afslutte den fuldgyldige integration af SELinux i den samme version af den stabile Linux-kernel v2.6. Kort tid efter blev SELinux de facto-standarden for et sikkert Linux-miljø og blev en del af de mest populære distributioner: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossar for SELinux

Identitet — Bruger SELinux er ikke det samme som den almindelige Unix/Linux-bruger-ID; de kan sameksistere på det samme system, men de er helt forskellige i essens. Hver standard Linux-konto kan svare til en eller flere i SELinux. Identiteten i SELinux er en del af den samlede sikkerhedskontekst, som definerer, hvilke domæner man kan få adgang til, og hvilke man ikke kan.
Domæner — I SELinux er et domæne konteksten for en kørsels-subjekt, dvs. en proces. Domænet bestemmer direkte den adgang, som processen har. Et domæne er grundlæggende en liste over, hvad processer kan gøre, eller hvilke handlinger en proces kan udføre med forskellige typer. Nogle eksempler på domæner: sysadm_t til systemadministration, og user_t, som er et almindeligt ikke-privilegeret bruger-domæne. Init-systemet init kører i domænet init_t, mens processen named kører i domænet named_t.
Roller — Det, der fungerer som mægler mellem domæner og brugere i SELinux. Roller definerer, hvilke domæner en bruger kan tilhøre, og hvilke typer objekter han kan få adgang til. En sådan adgangsafgrænsningsmekanisme forhindrer truslen om at udføre et privilegieoptrapningsangreb. Roller er indskrevet i modellen for Role Based Access Control (RBAC), der anvendes i SELinux.
Typer — Et attribut for Type Enforcement-listen, der tildeles et objekt og definerer, hvem der får adgang til det. Det ligner en domændefinition, undtagen at domænet anvendes på processen, mens typen anvendes på objekter såsom mapper, filer, sockets osv.
Subjekter og objekter — Processer er subjekter og kører i en bestemt kontekst eller sikkerhedsdomain. Ressourcer i operativsystemet: filer, mapper, sockets osv., er objekter, der får tildelt en bestemt type, med andre ord — et sekretionsniveau.
SELinux-politikker — For at beskytte systemet bruger SELinux forskellige politikker. SELinux-politikken bestemmer brugeres adgang til roller, roller til domæner og domæner til typer. Først godkendes brugeren til at få en rolle, derefter godkendes rollen til at få adgang til domæner. Endelig kan et domæne kun få adgang til visse typer objekter.

LSM og SELinux-arkitektur

På trods af navnet er LSM egentlig ikke indlæsbare moduler i Linux. Men ligesom SELinux er det direkte integreret i kernen. Enhver ændring af LSM's kildekode kræver en ny kompilering af kernen. Den relevante indstilling skal være aktiveret i kerneindstillingerne, ellers vil LSM-koden ikke blive aktiveret efter opstart. Men selv i dette tilfælde kan det aktiveres via OS's bootloader.

LSM kontrolstak

LSM har hooks i de centrale funktioner i kernen, som kan være relevante for kontroller. En af LSM's hovedfunktioner er, at de er opbygget som en stak. Dermed udføres de standardkontroller stadig, og hvert LSM-lag tilføjer kun ekstra kontrol- og styringselementer. Det betyder, at et forbud ikke kan tilbagekaldes. Dette vises på tegningen; hvis resultatet af de rutinemæssige DAC-kontroller er et afslag, når selv ikke LSM-hooks når at blive aktiveret.

SELinux har overtaget Flask-sikkerhedsarkitekturen fra forskningsoperativsystemet Fluke, især princippet om den mindste privilegium. Essensen af denne koncept, som navnet antyder, er at give brugeren eller processen kun de rettigheder, der er nødvendige for at udføre de tilsigtede handlinger. Dette princip implementeres ved hjælp af påtvungen adgangstype, således at kontrol af adgang i SELinux er baseret på modellen domæne => type.

Takket være den påtvungne adgangstype har SELinux langt mere betydelige muligheder for adgangsbegrænsning end den traditionelle DAC-model, der anvendes i Unix/Linux OS. For eksempel kan man begrænse nummeret på den netværksport, der vil blive anvendt af FTP-serveren, tillade skrivning og ændring af filer i en bestemt mappe, men ikke deres sletning.

De vigtigste komponenter i SELinux er som følger:

Policy Enforcement Server — Den primære mekanisme til organisering af adgangskontrol.
Sikkerhedspolitik database.
Interaktion med LSM-begivenhedshandleren.
Selinuxfs — En pseudo-filssystem, som er ligesom /proc og monteret i /sys/fs/selinux. Fyldes dynamisk af Linux-kernen under kørsel og indeholder filer, der indeholder oplysninger om status for SELinux.
Adgangsvektor cache — Et hjælpeværktøj til at forbedre ydeevnen.

Hvordan SELinux fungerer

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

En enhed, i SELinux-termer, udfører en tilladt handling på et objekt efter DAC-kontrol, som vist i det øverste billede. Denne anmodning om at udføre en operation sendes til LSM-hændelsesinterceptoren.
Derfra sendes anmodningen sammen med sikkerhedskonteksten for enheden og objektet til SELinux Abstraction and Hook Logic-modulet, der er ansvarligt for interaktionen med LSM.
Instance for beslutningstagning om enhedsadgang til objektet er Policy Enforcement Server, og der modtages data fra SELinux AnHL.
For at træffe en beslutning om adgang eller nægtelse henvender Policy Enforcement Server sig til cache-subsystemet for de mest anvendte regler, Access Vector Cache (AVC).
Hvis der ikke findes en beslutning for den relevante regel i cachen, sendes anmodningen videre til sikkerhedspolitikdatabase.
Resultatet af søgningen fra databasen og AVC returneres til Policy Enforcement Server.
Hvis den fundne politik stemmer overens med den anmodede handling, tillades operationen. Ellers nægtes operationen.

Administrere SELinux-indstillinger

SELinux fungerer i en af tre tilstande:

Enforcing — Streng overholdelse af sikkerhedspolitikker.
Permissive — Overtrædelse af begrænsninger tillades, og der gøres en tilsvarende bemærkning i loggen.
Disabled — Sikkerhedspolitikker er inaktive.

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

[admin@server ~]$ getenforce
Permissive

Ændring af tilstand indtil genstart, for eksempel ved at sætte til enforcing, eller 1. Parametret permissive svarer til det numeriske kode 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 fra setenfoce er, at ved opstart af operativsystemet vil SELinux-tilstanden blive indstillet i overensstemmelse med værdien af SELINUX-parametret i konfigurationsfilen. Derudover træder ændringer i enforcing disabled kun i kraft gennem redigering af filen /etc/selinux/config og efter genstart.

Se 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 attributter fra SELinux bruger nogle standardvæ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

I forhold til den almindelige ls -l-udskrivning er der her nogle ekstra felter i følgende format:

:::

Det sidste felt angiver noget, der minder om en hemmelighedsklassifikation og består af en kombination af to elementer:

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

Ændring af adgangskonfigurationer

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

[admin@server ~]$ semodule -l |wc -l #liste over alle moduler
408
[admin@server ~]$ semodule -e abrt #enable - aktivere modulet
[admin@server ~]$ semodule -d accountsd #disable - deaktivere modulet
[admin@server ~]$ semodule -r avahi #remove - fjerne modulet

Den første kommando semanage login binder SELinux-brugeren til operativsystembrugeren, den anden viser en liste. Til sidst fjerner den sidste kommando med flaget -r bindingen af SELinux-brugere til OS-konti. Forklaringen på syntaksen for 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 tilknytninger mellem brugere og roller i 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

Kommandoindstillinger:

-a tilføje en brugerdefineret rolletilknytningspost;
-l liste over bruger- og rollestilknytninger;
-d fjerne en brugerdefineret rolletilknytningspost;
-R liste over roller knyttet til brugeren;

Filer, porte og boolske værdier

Hver SELinux-modul leverer et sæt filmærkningsregler, men der kan også tilføjes egne regler, hvis det er 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 sagt tildeler, filtypene i henhold til de nuværende regler.

Tilsvarende er TCP/UDP-porte markeret på en sådan måde, at kun de relevante tjenester kan lytte til dem. For eksempel, for at webserveren kan lytte til port 8080, skal følgende kommando udføres.

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

Et betydeligt antal SELinux-moduler har parametre, der kan tage boolean-værdier. Den samlede liste over sådanne parametre kan ses med getsebool -a. Boolean-værdier kan ændres 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, hvor vi har installeret pgadmin4-web til administration af PostgreSQL-database på RHEL 7.6. Vi har gennemgået en lille quest med konfigurationen af pg_hba.conf, postgresql.conf og config_local.py, givet tilladelser til mapperne og 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, kontrollerer /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 det.

På dette punkt vil de fleste Linux-administratorer få en stærk fristelse til at køre setenforce 0, og så er sagen ude af verden. Jeg må indrømme, at jeg gjorde præcist det første gang. Det kan dog også være en løsning, men langt fra den bedste.

På trods af SELinux' klodsede konstruktioner kan det være brugervenligt. Det er tilstrækkeligt at installere pakken setroubleshoot og se systemloggen.

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

Vær opmærksom på, at tjenesten auditd skal genstartes på denne måde, og ikke med systemctl, på trods af at systemd er til stede i OS'et. I systemloggen vil det blive angivet ikke blot faktumet omkring blokeringen, men også årsagen og måden at omgå forbuddet på..

Udfør disse kommandoer: