Ce este SELinux și cum influențează securitatea serverului

Ce este SELinux și cum influențează securitatea serverului: este stratul de control al accesului din nucleul Linux care decide ce poate face fiecare proces, indiferent de permisiunile clasice ale fișierelor. Un server web compromis, cu SELinux activ, nu poate citi cheile SSH, nu poate scrie în /etc și nu poate deschide conexiuni spre exterior dacă politica nu îi permite, chiar dacă rulează cu un utilizator care, după chmod, ar avea voie.

Ghidul este scris pentru AlmaLinux 9 (și orice sistem din familia Red Hat), unde SELinux este activ implicit. Explică modelul pe scurt, apoi partea practică: cum citiți un refuz, cum îl reparați corect și care sunt cazurile pe care le veți întâlni pe un server web.

Ce este SELinux și cum influențează securitatea serverului

Două straturi de control

Permisiunile clasice (proprietar, grup, ceilalți, cu r, w, x) sunt control discreționar: proprietarul fișierului decide. SELinux adaugă control obligatoriu: o politică a sistemului decide, iar proprietarul nu o poate ocoli. O cerere de acces trebuie să treacă de ambele: întâi de permisiunile clasice, apoi de SELinux. De aceea, un fișier cu 777 rămâne inaccesibil serverului web dacă SELinux nu îi dă contextul potrivit, și de aceea „am pus 777 și tot nu merge” este simptomul clasic al unui refuz SELinux.

Contexte și tipuri

Fiecare proces și fiecare fișier are un context de securitate, afișat cu opțiunea -Z: utilizator, rol, tip și nivel. Pe servere contează tipul. Serverul web rulează în tipul httpd_t și poate citi fișiere de tipul httpd_sys_content_t, poate scrie în httpd_sys_rw_content_t și nu poate atinge fișiere cu alt tip, de exemplu user_home_t din dosarul personal al unui utilizator.

ls -Z /var/www/html/index.php          # unconfined_u:object_r:httpd_sys_content_t:s0
ps -eZ | grep httpd                     # system_u:system_r:httpd_t:s0
id -Z                                   # contextul sesiunii dumneavoastră

Politica implicită, numită targeted, izolează serviciile de rețea (web, baze de date, DNS, e-mail, SSH) în tipuri proprii și lasă restul sistemului, inclusiv sesiunile utilizatorilor, neconfinat. Un atacator care intră prin PHP se lovește de politică; un administrator care lucrează în terminal nu simte SELinux aproape deloc.

Modurile

• Enforcing: politica se aplică, refuzurile sunt blocate și înregistrate. Este modul de producție.
• Permissive: politica nu blochează, doar înregistrează ce ar fi blocat. Util pentru diagnostic, câteva minute.
• Disabled: oprit complet. Pe AlmaLinux 9, oprirea din /etc/selinux/config nu mai este acceptată; se face doar din linia de comandă a nucleului (selinux=0) și nu este recomandată de nimeni.

getenforce                  # Enforcing
sudo setenforce 0           # permissive temporar, până la repornire
sudo setenforce 1           # înapoi la enforcing
sestatus                    # starea completă, politica și modul

Trecerea temporară în permissive este unealta corectă de diagnostic: dacă problema dispare, era SELinux; dacă nu, căutați în altă parte. Reveniți la enforcing imediat după test.

Cum citiți un refuz

Refuzurile se scriu în jurnalul de audit, /var/log/audit/audit.log, ca mesaje AVC. Trei comenzi le fac lizibile:

sudo ausearch -m avc -ts recent                 # refuzurile din ultimele 10 minute
sudo dnf install setroubleshoot-server -y
sudo sealert -a /var/log/audit/audit.log        # explicații și sugestii pentru fiecare refuz
sudo journalctl -t setroubleshoot --since today # aceleași explicații, din jurnalul de sistem

Un mesaj AVC spune: procesul sursă (scontext, de exemplu httpd_t), ținta (tcontext, de exemplu user_home_t), clasa (file, dir, tcp_socket) și operația refuzată (read, write, name_connect). Cu aceste patru elemente, cauza este aproape întotdeauna una dintre cele trei de mai jos. sealert propune și o soluție, de obicei corectă pentru cazurile obișnuite; pentru cele neobișnuite propune un modul de politică, pe care îl acceptați doar dacă înțelegeți ce permite.

Cele trei reparații corecte

1. Contextul fișierelor: restorecon

Cel mai frecvent caz: fișiere copiate sau mutate din dosarul personal în /var/www păstrează contextul vechi (mv păstrează contextul, cp îl reface). Serverul web nu le poate citi. Reparația readuce contextele la cele definite de politică pentru cale:

sudo restorecon -Rv /var/www/site

Dacă site-ul stă într-un dosar neobișnuit (/srv/site sau /home/site/public), politica nu știe ce context să pună; îi spuneți cu semanage fcontext, o singură dată, apoi restorecon:

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/srv/site/incarcari(/.*)?"
sudo restorecon -Rv /srv/site

Regula pe care o aplicăm: doar dosarele în care aplicația chiar scrie (încărcări, cache, sesiuni) primesc tipul rw; restul rămâne doar citire. Este exact protecția pe care o vreți: un script compromis nu poate modifica fișierele PHP ale site-ului.

2. Booleenii: setsebool

Politica are comutatoare pentru comportamentele frecvente care nu sunt permise implicit. Cele pe care le activăm des pe servere web:

sudo getsebool -a | grep httpd                              # lista completă
sudo setsebool -P httpd_can_network_connect on              # PHP se conectează la API-uri externe sau la Redis
sudo setsebool -P httpd_can_network_connect_db on           # doar la baze de date de la distanță
sudo setsebool -P httpd_can_sendmail on                     # aplicația trimite e-mail
sudo setsebool -P httpd_unified on                          # scriere în tot conținutul web (evitați dacă puteți)

Opțiunea -P face schimbarea permanentă. Activați booleenul cel mai îngust care rezolvă problema: httpd_can_network_connect_db în loc de httpd_can_network_connect, dacă aplicația are nevoie doar de baza de date.

3. Porturile: semanage port

Un serviciu care ascultă pe un port neobișnuit este blocat: SSH mutat pe 2200, un server web pe 8081, o aplicație Node pe 3000 spre care Apache face proxy. Adăugați portul la tipul serviciului:

sudo semanage port -l | grep ssh                       # porturile permise acum
sudo semanage port -a -t ssh_port_t -p tcp 2200
sudo semanage port -a -t http_port_t -p tcp 8081

Dacă portul este deja definit pentru alt tip, folosiți -m (modificare) în loc de -a. Pachetul policycoreutils-python-utils aduce comanda semanage, dacă lipsește.

SELinux și serviciile obișnuite ale unui server web

• PHP-FPM: rulează în httpd_t, deci aceleași contexte și booleeni ca Apache; dosarul de sesiuni și cel de încărcări au nevoie de httpd_sys_rw_content_t.
• Nginx: același tip httpd_t, inclusiv pentru rolul de proxy; proxy-ul spre un port neobișnuit cere semanage port pe http_port_t, iar conexiunea spre aplicație cere httpd_can_network_connect sau, mai îngust, httpd_can_network_relay. Configurarea este în articolul despre Nginx ca reverse proxy.
• MariaDB și MySQL: tipul mysqld_t; mutarea datelor în alt dosar decât /var/lib/mysql cere semanage fcontext cu mysqld_db_t.
• Redis și Memcached: tipuri proprii; conectarea PHP la ele prin rețea cere httpd_can_network_connect, iar prin socket Unix, un context potrivit pe fișierul de socket. Instalarea este în ghidul despre configurarea unui server de cache Redis.
• FTP: scrierea în dosarele personale cere ftpd_full_access sau ftp_home_dir, în funcție de configurare.
• Cron: scripturile rulate din cron care scriu în /var/www au nevoie de contexte corecte pe fișierele create; restorecon la finalul scriptului rezolvă.

Ce nu faceți

• Nu treceți în permissive „până rezolvăm” și uitați acolo: după o săptămână, jurnalul e plin și protecția e zero.
• Nu generați module de politică cu audit2allow pentru orice refuz: un modul care permite httpd_t să scrie în etc_t rezolvă „eroarea” și anulează rostul SELinux. Folosiți audit2allow doar după ce ați epuizat cele trei reparații de mai sus, și citiți modulul înainte de a-l încărca.
• Nu folosiți chcon pentru schimbări permanente: contextul pus cu chcon dispare la următorul restorecon sau la reetichetare. semanage fcontext plus restorecon este calea.
• Nu montați dosare din sistem în containere fără opțiunea :z sau :Z; Docker și Podman le etichetează corect doar așa, cum arătăm în ghidul despre Docker pe Linux.

Cazuri de pe serverele clienților

Un site migrat de pe Ubuntu pe AlmaLinux dădea 403 pe toate paginile, cu permisiuni 755/644 perfecte. Contextul fișierelor era user_home_t, de la dezarhivarea în dosarul personal și mutarea cu mv; restorecon -Rv a rezolvat în trei secunde. Un magazin nu putea trimite comenzile spre procesatorul de plăți: refuz name_connect din httpd_t spre portul 443; httpd_can_network_connect on. Un server cu SSH pe 2200 nu pornea serviciul după repornire: semanage port lipsea, iar jurnalul de sistem spunea doar „bind: Permission denied”; ausearch a arătat refuzul. Un modul de cache scria sesiuni în /var/lib/php/session cu erori intermitente: dosarul avea contextul corect, dar un script de curățare rulat din cron ca alt utilizator îl recreea cu context greșit; semanage fcontext plus restorecon în script.

În toate cazurile, timpul de diagnostic cu ausearch și sealert a fost sub zece minute. SELinux nu e greu; e doar un jurnal în plus de citit, iar contextul general de întărire în care se încadrează este descris în ghidul de securitate pentru AlmaLinux 9. Pentru permisiunile clasice, de sub SELinux, vedeți ghidul despre chmod și chown, iar pentru serverele cu cPanel, care configurează singure contextele pentru conturi, particularitățile sunt în ghidul despre instalarea cPanel/WHM pe AlmaLinux 9.

Surse

• Wiki AlmaLinux: starea SELinux în AlmaLinux 9 și notele de lansare privind dezactivarea.
• Documentația nucleului Linux: modulele de securitate (LSM) și arhitectura SELinux în nucleu.