🥇Linux sikkerhetssystemer

En av grunnene til den enorme suksessen til Linux OS på innebygde, mobile enheter og servere er den ganske høye sikkerheten til kjernen, relaterte tjenester og applikasjoner. Men hvis ta en nærmere titt til arkitekturen til Linux-kjernen, så er det umulig å finne en firkant som er ansvarlig for sikkerheten i den. Hvor skjuler Linux-sikkerhetsundersystemet seg og hva består det av?

Bakgrunn om Linux sikkerhetsmoduler og SELinux

Security Enhanced Linux er et sett med regler og tilgangsmekanismer basert på obligatoriske og rollebaserte tilgangsmodeller for å beskytte Linux-systemer mot potensielle trusler og korrigere manglene ved Discretionary Access Control (DAC), det tradisjonelle Unix-sikkerhetssystemet. Prosjektet har sin opprinnelse i innvollene til US National Security Agency, og ble direkte utviklet hovedsakelig av entreprenørene Secure Computing Corporation og MITER, samt en rekke forskningslaboratorier.

Linux sikkerhetsmoduler

Linus Torvalds kom med en rekke kommentarer om nye NSA-utviklinger slik at de kunne inkluderes i hovedlinjen i Linux-kjernen. Han beskrev et generelt miljø, med et sett med interceptorer for å kontrollere operasjoner med objekter og et sett med visse beskyttende felt i kjernedatastrukturer for å lagre de tilsvarende attributtene. Dette miljøet kan deretter brukes av lastbare kjernemoduler for å implementere enhver ønsket sikkerhetsmodell. LSM gikk fullstendig inn i Linux-kjernen v2.6 i 2003.

LSM-rammeverket inkluderer vaktfelt i datastrukturer og kall til avskjæringsfunksjoner på kritiske punkter i kjernekoden for å manipulere dem og utføre tilgangskontroll. Den legger også til funksjonalitet for registrering av sikkerhetsmoduler. /sys/kernel/security/lsm-grensesnittet inneholder en liste over aktive moduler på systemet. LSM-kroker lagres i lister som kalles opp i den rekkefølgen som er spesifisert i CONFIG_LSM. Detaljert dokumentasjon om kroker er inkludert i overskriftsfilen include/linux/lsm_hooks.h.

LSM-undersystemet gjorde det mulig å fullføre full integrasjon av SELinux med samme versjon av den stabile Linux-kjernen v2.6. Nesten umiddelbart ble SELinux de facto-standarden for et sikkert Linux-miljø og ble inkludert i de mest populære distribusjonene: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

SELinux ordliste

identitet — SELinux-brukeren er ikke den samme som den vanlige Unix/Linux-bruker-IDen; de kan eksistere side om side på samme system, men er helt forskjellige i hovedsak. Hver standard Linux-konto kan tilsvare en eller flere i SELinux. SELinux-identiteten er en del av den generelle sikkerhetskonteksten, som avgjør hvilke domener du kan og ikke kan bli med.
domener - I SELinux er et domene utførelseskonteksten til et emne, det vil si en prosess. Domenet bestemmer direkte tilgangen en prosess har. Et domene er i utgangspunktet en liste over hva prosesser kan gjøre eller hva en prosess kan gjøre med ulike typer. Noen eksempler på domener er sysadm_t for systemadministrasjon, og user_t som er et normalt ikke-privilegert brukerdomene. Init-systemet kjører i init_t-domenet, og den navngitte prosessen kjører i named_t-domenet.
rolle — Det som fungerer som mellomledd mellom domener og SELinux-brukere. Roller bestemmer hvilke domener en bruker kan tilhøre og hvilke typer objekter de har tilgang til. Denne tilgangskontrollmekanismen forhindrer trusselen om eskaleringsangrep. Roller er skrevet inn i sikkerhetsmodellen Role Based Access Control (RBAC) som brukes i SELinux.
typer — Et Type Enforcement-listeattributt som er tilordnet et objekt og bestemmer hvem som har tilgang til det. Ligner på domenedefinisjonen, bortsett fra at domenet gjelder for en prosess, og typen gjelder for objekter som kataloger, filer, sockets, etc.
Emner og objekter – Prosesser er subjekter og kjøres i en bestemt kontekst, eller sikkerhetsdomene. Operativsystemressurser: filer, kataloger, sockets, etc., er objekter som er tildelt en bestemt type, med andre ord et personvernnivå.
SELinux retningslinjer — SELinux bruker en rekke retningslinjer for å beskytte systemet. SELinux-policyen definerer brukernes tilgang til roller, roller til domener og domener til typer. Først er brukeren autorisert til å få en rolle, deretter får rollen tilgang til domener. Til slutt kan et domene bare ha tilgang til visse typer objekter.

LSM og SELinux arkitektur

Til tross for navnet, er ikke LSM-er generelt lastbare Linux-moduler. I likhet med SELinux er den imidlertid direkte integrert i kjernen. Enhver endring av LSM-kildekoden krever en ny kjernekompilering. Det tilsvarende alternativet må være aktivert i kjerneinnstillingene, ellers vil ikke LSM-koden aktiveres etter oppstart. Men selv i dette tilfellet kan det aktiveres av OS bootloader-alternativet.

LSM sjekkstabel

LSM er utstyrt med kroker i kjernekjernefunksjoner som kan være aktuelle for kontroller. En av hovedtrekkene til LSM-er er at de er stablet. Dermed blir standardkontrollene fortsatt utført, og hvert lag av LSM legger bare til ytterligere kontroller og kontroller. Det betyr at forbudet ikke kan rulles tilbake. Dette er vist i figuren; hvis resultatet av rutinemessige DAC-kontroller er en feil, vil saken ikke engang nå LSM-krokene.

SELinux tar i bruk Flask-sikkerhetsarkitekturen til Fluke forskningsoperativsystem, spesielt prinsippet om minste privilegium. Essensen av dette konseptet, som navnet antyder, er å gi brukeren eller behandle bare de rettighetene som er nødvendige for å utføre de tiltenkte handlingene. Dette prinsippet er implementert ved bruk av tvungen tilgangstasting, og dermed er tilgangskontroll i SELinux basert på domene => typemodellen.

Takket være tvungen tilgangsskriving har SELinux mye større tilgangskontrollmuligheter enn den tradisjonelle DAC-modellen som brukes i Unix/Linux-operativsystemer. Du kan for eksempel begrense nettverksportnummeret som ftp-serveren vil koble til, tillate skriving og endring av filer i en bestemt mappe, men ikke slette dem.

Hovedkomponentene til SELinux er:

Policy Enforcement Server — Hovedmekanismen for organisering av tilgangskontroll.
Systemsikkerhetspolicydatabase.
Interaksjon med LSM-hendelsesavskjæreren.
Selinuxfs - Pseudo-FS, det samme som /proc og montert i /sys/fs/selinux. Dynamisk fylt av Linux-kjernen ved kjøretid og inneholder filer som inneholder SELinux-statusinformasjon.
Få tilgang til Vector Cache — En hjelpemekanisme for å øke produktiviteten.

Hvordan SELinux fungerer

Det hele fungerer slik.

Et bestemt emne, i SELinux-termer, utfører en tillatt handling på et objekt etter en DAC-sjekk, som vist på det øverste bildet. Denne forespørselen om å utføre en operasjon går til LSM-hendelsesavfangeren.
Derfra sendes forespørselen, sammen med emne- og objektsikkerhetskonteksten, til SELinux Abstraction and Hook Logic-modulen, som er ansvarlig for å samhandle med LSM.
Beslutningsmyndigheten for et subjekts tilgang til et objekt er Policy Enforcement Server, og den mottar data fra SELinux AnHL.
For å ta avgjørelser om tilgang eller nektelse, henvender Policy Enforcement Server seg til Access Vector Cache (AVC) caching-delsystemet for de mest brukte reglene.
Hvis en løsning for den tilsvarende regelen ikke finnes i hurtigbufferen, sendes forespørselen videre til sikkerhetspolicydatabasen.
Søkeresultatet fra databasen og AVC returneres til Policy Enforcement Server.
Hvis policyen som ble funnet samsvarer med den forespurte handlingen, er operasjonen tillatt. Ellers er operasjonen forbudt.

Administrere SELinux-innstillinger

SELinux opererer i en av tre moduser:

Håndheve - Streng overholdelse av sikkerhetspolicyer.
Permissive - Brudd på restriksjoner er tillatt; et tilsvarende notat gjøres i journalen.
Deaktivert – Sikkerhetsretningslinjer er ikke i kraft.

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

[admin@server ~]$ getenforce
Permissive

Endre modus før omstart, for eksempel sette den til å håndheve, eller 1. Den tillatelige parameteren tilsvarer den numeriske koden 0.

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

Du kan også endre modusen ved å 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

Forskjellen med setenfoce er at når operativsystemet starter, vil SELinux-modusen settes i samsvar med verdien av SELINUX-parameteren i konfigurasjonsfilen. I tillegg vil endringer for å håndheve <=> deaktivert kun tre i kraft ved å redigere filen /etc/selinux/config og etter 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
For å se SELinux-attributter, bruker noen standardverktøy 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 normale utgangen av ls -l, er det flere tilleggsfelt i følgende format:

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

Det siste feltet angir noe som en sikkerhetsklassifisering og består av en kombinasjon av to elementer:

s0 - signifikans, også skrevet som lavnivå-høynivåintervall
c0, c1… c1023 - kategori.

Endring av tilgangskonfigurasjon

Bruk semodule for å laste, legge til 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 lag semanage pålogging kobler SELinux-brukeren til brukeren av operativsystemet, den andre viser en liste. Til slutt fjerner den siste kommandoen med -r-bryteren tilordningen av SELinux-brukere til OS-kontoer. En forklaring av syntaksen for MLS/MCS Range-verdier er i forrige seksjon.

[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
Lag semanage bruker brukes til å administrere tilordninger mellom SELinux-brukere 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

Kommandoparametere:

-a legge til egendefinert rollekartleggingsoppføring;
-l liste over matchende brukere og roller;
-d slette brukerrolle kartlegging oppføring;
-R liste over roller knyttet til brukeren;

Filer, porter og boolske verdier

Hver SELinux-modul gir et sett med regler for filmerking, men du kan også legge til dine egne regler om nødvendig. For eksempel vil vi at webserveren skal ha tilgangsrettigheter til /srv/www-mappen.

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

Den første kommandoen registrerer nye merkingsregler, og den andre tilbakestiller, eller snarere setter, filtypene i samsvar med gjeldende regler.

På samme måte er TCP/UDP-porter merket på en slik måte at bare de aktuelle tjenestene kan lytte på dem. For eksempel, for at webserveren skal lytte på port 8080, må du kjøre kommandoen.

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

Et betydelig antall SELinux-moduler har parametere som kan ta boolske verdier. Hele listen over slike parametere kan sees ved hjelp av getsebool -a. Du kan endre boolske verdier ved å bruke 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å tilgang til Pgadmin-webgrensesnittet

La oss se på et praktisk eksempel: vi installerte pgadmin7.6-web på RHEL 4 for å administrere PostgreSQL-databasen. Vi gikk litt søken med innstillingene til pg_hba.conf, postgresql.conf og config_local.py, angi mappetillatelser, installerte de manglende Python-modulene fra pip. Alt er klart, vi lanserer og tar imot 500 Intern serverfeil.

Vi starter med de typiske mistenkte, og sjekker /var/log/httpd/error_log. Det er noen interessante oppføringer 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 tidspunktet vil de fleste Linux-administratorer bli sterkt fristet til å kjøre setencorce 0, og det vil være slutten på det. Helt ærlig, jeg gjorde akkurat det første gangen. Dette er selvsagt også en vei ut, men langt fra den beste.

Til tross for de tungvinte designene, kan SELinux være brukervennlig. Bare installer setroubleshoot-pakken og se systemloggen.

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

Vær oppmerksom på at revisjonstjenesten må startes på nytt på denne måten, og ikke bruke systemctl, til tross for tilstedeværelsen av systemd i operativsystemet. I systemloggen vil bli indikert ikke bare blokkeringen, men også årsaken og måte å overvinne forbudet.

Vi utfører disse kommandoene:

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

Vi sjekker tilgangen til pgadmin4-nettsiden, alt fungerer.

Kilde: www.habr.com

Linux sikkerhetssystemer