🥇Linux sikkerhedssystemer

En af grundene til Linux OS's enorme succes på indlejrede, mobile enheder og servere er den ret høje grad af sikkerhed for kernen, relaterede tjenester og applikationer. Men hvis se nærmere til Linux-kernens arkitektur, så er det umuligt at finde en firkant i den, der er ansvarlig for sikkerheden som sådan. Hvor gemmer sig Linux-sikkerhedsundersystemet, og hvad består det af?

Baggrund om Linux-sikkerhedsmoduler og SELinux

Sikkerhedsforbedret Linux er et sæt regler og en adgangsmekanisme baseret på de obligatoriske og rollebaserede adgangsmodeller for at beskytte Linux-systemer mod potentielle trusler og rette op på svaghederne ved Discretionary Access Control (DAC), det traditionelle Unix-sikkerhedssystem. Projektet opstod i det amerikanske National Security Agencys indvolde, og entreprenørerne Secure Computing Corporation og MITER samt en række forskningslaboratorier var direkte involveret i udviklingen.

Linux sikkerhedsmoduler

Linus Torvalds bidrog med en række noter om nye NSA-udviklinger, så de kunne inkluderes i hovedgrenen af Linux-kernen. Han beskrev et fælles miljø med et sæt interceptorer til styring af operationer på objekter og et sæt af nogle beskyttende felter i kernedatastrukturerne til lagring af de tilsvarende attributter. Dette miljø kan derefter bruges af indlæsbare kernemoduler til at implementere enhver ønsket sikkerhedsmodel. LSM gik helt ind i Linux-kernen v2.6 i 2003.

LSM-rammen inkluderer vagtfelter i datastrukturer og opkald til aflytning af funktioner på kritiske punkter i kernekoden for at administrere dem og udføre adgangskontrol. Det tilføjer også funktionalitet til registrering af sikkerhedsmoduler. /sys/kernel/security/lsm-grænsefladen indeholder en liste over aktive moduler i systemet. LSM hooks gemmes i lister, der kaldes i den rækkefølge, der er angivet i CONFIG_LSM. Detaljeret hook-dokumentation er inkluderet i include/linux/lsm_hooks.h header-filen.

LSM-undersystemet gjorde det muligt at fuldføre den fulde integration af SELinux af samme version af den stabile Linux-kerne v2.6. Bogstaveligt talt med det samme 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.

SELinux ordliste

identitet - SELinux-brugeren er ikke den samme som den sædvanlige Unix/Linux-bruger-id, de kan eksistere side om side på det samme system, men de er helt forskellige i essensen. Hver standard Linux-konto kan svare til en eller flere i SELinux. SELinux-identiteten er en del af den overordnede sikkerhedskontekst, der bestemmer, hvilke domæner du kan og ikke kan tilslutte dig.
domæner - I SELinux er domænet emnets eksekveringskontekst, altså processen. Domænet definerer direkte den adgang, en proces har. Et domæne er dybest 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 er sysadm_t til systemadministration og user_t som er et almindeligt uprivilegeret brugerdomæne. Init-systemet kører i init_t-domænet, og den navngivne proces kører i named_t-domænet.
rolle - Noget der fungerer som mellemled mellem domæner og SELinux-brugere. Roller definerer hvilke domæner en bruger kan tilhøre, og hvilke typer objekter brugeren har adgang til. En sådan adgangskontrolmekanisme forhindrer truslen om et privilegieeskaleringsangreb. Roller er skrevet ind i den rollebaserede adgangskontrol (RBAC) sikkerhedsmodel, der bruges i SELinux.
typer — En Type Enforcement-listeattribut, der er tildelt til et objekt og bestemmer, hvem der kan få adgang til det. Svarende til domænedefinitionen, bortset fra at domænet gælder for en proces, og typen gælder for objekter såsom mapper, filer, sockets osv.
Emner og objekter - Processer er emner og kører i en bestemt kontekst eller sikkerhedsdomæne. Operativsystemressourcer: filer, mapper, sockets osv. er objekter, der er tildelt en bestemt type, med andre ord et privatlivsniveau.
SELinux politikker - SELinux bruger en række forskellige politikker til at beskytte systemet. SELinux-politikken definerer brugeradgang til roller, roller til domæner og domæner til typer. Først er brugeren autoriseret til at opnå en rolle, derefter er rollen autoriseret til at få adgang til domæner. Endelig kan et domæne kun have adgang til bestemte typer objekter.

LSM og SELinux arkitektur

På trods af navnet er LSM'er generelt ikke indlæsbare Linux-moduler. Men ligesom SELinux er den direkte integreret i kernen. Enhver ændring af LSM-kildekoden kræver en ny kernekompilering. Den tilsvarende mulighed skal være aktiveret i kerneindstillingerne, ellers vil LSM-koden ikke blive aktiveret efter opstart. Men selv i dette tilfælde kan det aktiveres af OS bootloader-indstillingen.

LSM check stak

LSM er udstyret med kroge i kerne-kernefunktioner, der kan være relevante for checks. Et af hovedtrækkene ved LSM er, at de er stakbaserede. Standardkontrollerne udføres således stadig, og hvert LSM-lag tilføjer kun yderligere kontroller og kontroller. Det betyder, at forbuddet ikke kan rulles tilbage. Dette er vist i figuren, hvis resultatet af rutinemæssige DAC-tjek er en fejl, vil det ikke engang nå LSM-krogene.

SELinux adopterede Flask-sikkerhedsarkitekturen i Fluke forskningsoperativsystemet, specifikt princippet om mindste privilegium. Essensen af dette koncept, som deres navn antyder, er kun at give brugeren eller behandle de rettigheder, der er nødvendige for gennemførelsen af de påtænkte handlinger. Dette princip er implementeret ved hjælp af tvungen adgangstastning, så SELinux's adgangskontrol er baseret på domæne => type modellen.

Gennem tvungen adgangstastning har SELinux meget større adgangskontrolmuligheder end den traditionelle DAC-model, der bruges i Unix/Linux-operativsystemer. For eksempel kan du begrænse netværksportnummeret, der vil ske med ftp-serveren, tillade skrivning og ændring af filer i en bestemt mappe, men ikke slette dem.

Hovedkomponenterne i SELinux er:

Politikhåndhævelsesserver — Hovedmekanismen til organisering af adgangskontrol.
Systemsikkerhedspolitikdatabase.
Interaktion med LSM-begivenhedslytteren.
Selinuxfs - Pseudo-FS, det samme som /proc og monteret i /sys/fs/selinux. Befolkes dynamisk af Linux-kernen under kørsel og indeholder filer, der indeholder SELinux-statusinformation.
Få adgang til Vector Cache - Hjælpemekanisme til at forbedre ydeevnen.

Sådan virker SELinux

Det hele fungerer sådan her.

Et emne, i SELinux-termer, udfører en tilladt handling på et objekt efter en DAC-kontrol, som vist på det øverste billede. Denne operationsanmodning går til LSM-hændelseslytteren.
Derfra videregives anmodningen, sammen med sikkerhedskonteksten for emnet og objektet, til SELinux Abstraction and Hook Logic-modulet, der er ansvarligt for at interagere med LSM.
Politikhåndhævelsesserveren er den beslutningstagende myndighed om subjektets adgang til objektet, og den modtager data fra SELinux AnHL.
For at træffe en beslutning om adgang eller forbud henviser Policy Enforcement Server til caching-undersystemet for de mest brugte Access Vector Cache (AVC)-regler.
Hvis en løsning for den tilsvarende regel ikke findes i cachen, sendes anmodningen videre til sikkerhedspolitikdatabasen.
Søgeresultatet fra databasen og AVC returneres til Policy Enforcement Server.
Hvis den fundne politik er i overensstemmelse med den anmodede handling, er handlingen tilladt. Ellers er operationen forbudt.

Håndtering af SELinux-indstillinger

SELinux fungerer i en af tre tilstande:

Håndhævelse - Streng overholdelse af sikkerhedspolitikker.
Tilladt - Overtrædelse af restriktioner er tilladt; en tilsvarende note er lavet i journalen.
Deaktiveret – Sikkerhedspolitikker er ikke i kraft.

Du kan se hvilken tilstand SELinux er i med følgende kommando.

[admin@server ~]$ getenforce
Permissive

Ændring af tilstanden før genstart, for eksempel, indstil den til at håndhæve, eller 1. Den tilladelige parameter svarer til den numeriske kode 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое

Du kan også ændre tilstanden 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=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

Forskellen med setenfoce er, at når operativsystemet starter, vil SELinux-tilstanden blive indstillet i overensstemmelse med værdien af SELINUX-parameteren i konfigurationsfilen. Derudover træder håndhævelse af <=> deaktiverede ændringer kun i kraft ved at redigere filen /etc/selinux/config og efter en genstart.

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
For at se SELinux-attributter 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

Sammenlignet med det normale ls -l output, er der flere ekstra felter i følgende format:

<user>:<role>:<type>:<level>

Det sidste felt betegner noget som en sikkerhedsklassifikation og består af en kombination af to elementer:

s0 - signifikans, også skrevet som lav-højt niveau interval
c0, c1… c1023 er kategorien.

Ændring af adgangskonfiguration

Brug semodule til at indlæse, tilføje og fjerne 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ørste hold semanage login forbinder en SELinux-bruger med en operativsystembruger, den anden viser den. Endelig fjerner den sidste kommando med -r-kontakten tilknytningen af SELinux-brugere til OS-konti. En forklaring af syntaksen for MLS/MCS Range-værdier er i forrige afsnit.

[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 bruger bruges til at administrere kortlægninger mellem SELinux-brugere og 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_u

Kommandoparametre:

-a tilføje brugerdefineret rolle mapping post;
-l liste over matchende brugere og roller;
-d slet brugerrolletilknytningsindgang;
-R liste over roller knyttet til brugeren;

Filer, porte og booleaner

Hvert SELinux-modul giver et sæt af filmarkeringsregler, men du kan også tilføje dine egne regler, hvis det er nødvendigt. For eksempel ønsker vi, at webserveren skal have 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 markeringsregler, og den anden nulstiller, eller rettere eksponerer, filtyper i overensstemmelse med de nuværende regler.

Ligeledes er TCP/UDP-porte markeret på en sådan måde, at kun de relevante tjenester kan lytte på dem. For at en webserver for eksempel kan lytte på port 8080, skal du køre en kommando.

[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. Hele listen over sådanne parametre kan ses ved hjælp af getsebool -a. Du kan ændre booleske værdier ved hjælp af 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å adgang til Pgadmin-webgrænsefladen

Lad os se på et praktisk eksempel: vi installerede pgadmin7.6-web på RHEL 4 for at administrere PostgreSQL-databasen. Vi gik lidt Quest med opsætning af pg_hba.conf, postgresql.conf og config_local.py, sæt rettighederne til mapperne, installerede de manglende Python-moduler fra pip. Alt er klar, løb og få 500 Intern serverfejl.

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

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

På dette tidspunkt vil de fleste Linux-administratorer blive stærkt fristet til at køre setencorce 0 og være færdige med det. Helt ærligt gjorde jeg netop det første gang. Dette er selvfølgelig også en vej ud, men langt fra den bedste.

På trods af de besværlige designs kan SELinux være brugervenlig. Bare installer setroubleshoot-pakken og se systemloggen.

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

Bemærk, at den auditd-tjeneste skal genstartes på denne måde, og ikke med systemctl, på trods af tilstedeværelsen af systemd i OS. I systemloggen vil blive angivet ikke kun det faktum at blokere, men også årsagen og måde at overvinde forbuddet på.

Vi udfører disse kommandoer:

[admin@server ~]$ setsebool -P httpd_can_network_connect 1 [admin@server ~]$ setsebool -P httpd_can_network_connect_db 1

Vi tjekker adgangen til pgadmin4-websiden, alt virker.

Kilde: www.habr.com

Linux sikkerhedssystemer