Implementarea controlului accesului obligatoriu cu SELinux sau AppArmor în Linux

Pentru a depăși limitările și pentru a crește mecanismele de securitate oferite de permisiunile standard ugo/rwx și listele de control al accesului, Agenția de Securitate Națională a Statelor Unite (NSA) a conceput un ugo/rwx standard. MetodaMandatory Access Control (MAC) cunoscută sub numele de SELinux (prescurtare de la Security Enhanced Linux) pentru a limita, printre altele, capacitatea proceselor de a accesați sau efectuați alte operațiuni asupra obiectelor de sistem (cum ar fi fișiere, directoare, porturi de rețea etc.) cu cea mai mică permisiune posibilă, permițând totuși modificări ulterioare ale acestui model.

Un alt MAC popular și utilizat pe scară largă este AppArmor, care, pe lângă caracteristicile oferite de SELinux, include un mod de învățare care permite sistemului să \învețe<” cum se comportă o anumită aplicație și pentru a stabili limite prin configurarea profilurilor pentru utilizarea în siguranță a aplicației.

În CentOS 7, SELinux este încorporat în nucleul propriu-zis și este activat în mod implicit Implementare (mai multe despre asta în secțiunea următoare), spre deosebire de openSUSE și Ubuntu care folosesc AppArmor.

În acest articol, vom explica elementele esențiale ale SELinux și AppArmor și cum să utilizați unul dintre aceste instrumente în beneficiul dumneavoastră, în funcție de distribuția aleasă.

Introducere în SELinux și cum se utilizează pe CentOS 7

Linux Security Enhanced poate funcționa în două moduri diferite:

  1. Implementarea: SELinux interzice accesul pe baza regulilor politicii SELinux, un set de linii directoare care controlează motorul de securitate.
  2. Permisiv: SELinux nu interzice accesul, dar refuzurile sunt înregistrate pentru acțiuni care ar fi fost refuzate dacă ar fi rulat în modul de aplicare.

SELinux poate fi, de asemenea, dezactivat. Deși nu este un mod de funcționare în sine, este totuși o opțiune. Cu toate acestea, este mai bine să înveți cum să folosești acest instrument decât să-l ignori. Ține minte!

Pentru a afișa modul curent al SELinux, utilizați getenforce. Dacă doriți să comutați modul de funcționare, utilizați setenforce 0 (pentru a-l seta la Permisiv) sau setenforce 1 (Implementare puternic>).

Deoarece această modificare nu va supraviețui unei reporniri, va trebui să editați fișierul /etc/selinux/config și să setați variabila SELINUX la oricare implicare, permisiv sau dezactivat pentru a obține persistență la reporniri:

Pe o notă secundară, dacă getenforce returnează Disabled, va trebui să editați /etc/selinux/config cu modul de operare dorit și să reporniți. În caz contrar, nu veți putea seta (sau comuta) modul de funcționare cu setenforce.

Una dintre utilizările tipice ale setenforce constă în comutarea între modurile SELinux (de la aplicare la permisivă sau invers) pentru a depana o aplicație care se comportă prost sau nu funcționează conform așteptărilor. Dacă funcționează după ce setați SELinux în modul Permisiv, puteți fi sigur că vă uitați la o problemă de permisiuni SELinux.

Două cazuri clasice în care cel mai probabil vom avea de-a face cu SELinux sunt:

  1. Schimbarea portului implicit în care ascultă un demon.
  2. Setarea directivei DocumentRoot pentru o gazdă virtuală în afara /var/www/html.

Să aruncăm o privire la aceste două cazuri folosind următoarele exemple.

Unul dintre primele lucruri pe care majoritatea administratorilor de sistem îl fac pentru a-și securiza serverele este să schimbe portul pe care ascultă demonul SSH, mai ales pentru a descuraja scanerele de porturi și atacatorii externi. Pentru a face acest lucru, folosim directiva Port în /etc/ssh/sshd_config urmată de noul număr de port, după cum urmează (vom folosi portul 9999 în acest caz):

Port 9999

După încercarea de a reporni serviciul și verificarea stării acestuia, vom vedea că nu a reușit să pornească:

# systemctl restart sshd
# systemctl status sshd

Dacă ne uităm la /var/log/audit/audit.log, vom vedea că sshd a fost împiedicat să pornească pe portul 9999 de SELinux, deoarece acesta este un port rezervat pentru serviciul JBoss Management (mesajele de jurnal SELinux includ cuvântul „AVC”, astfel încât să fie ușor identificate din alte mesaje):

# cat /var/log/audit/audit.log | grep AVC | tail -1

În acest moment, majoritatea oamenilor ar dezactiva probabil SELinux, dar noi nu o vom face. Vom vedea că există o modalitate prin care SELinux și sshd ascultă pe un alt port, să trăiască în armonie împreună. Asigurați-vă că aveți pachetul policycoreutils-python instalat și rulați:

# yum install policycoreutils-python

Pentru a vizualiza o listă cu porturile pe care SELinux permite sshd să asculte. În imaginea următoare putem vedea că portul 9999 a fost rezervat pentru alt serviciu și, prin urmare, nu îl putem folosi pentru a rula un alt serviciu deocamdată:

# semanage port -l | grep ssh

Bineînțeles că am putea alege un alt port pentru SSH, dar dacă suntem siguri că nu va trebui să folosim această mașină specifică pentru niciun serviciu legat de JBoss, apoi putem modifica regula SELinux existentă și aloca acel port la SSH în schimb:

# semanage port -m -t ssh_port_t -p tcp 9999

După aceea, putem folosi prima comandă semanage pentru a verifica dacă portul a fost alocat corect sau opțiunile -lC (prescurtare pentru list custom):

# semanage port -lC
# semanage port -l | grep ssh

Acum putem reporni SSH și ne putem conecta la serviciu folosind portul 9999. Rețineți că această modificare VA supraviețui unei reporniri.

Dacă trebuie să configurați o gazdă virtuală Apache utilizând un alt director decât /var/www/html ca DocumentRoot (să spunem, de exemplu, /websrv/sites /gabriel/public_html):

DocumentRoot “/websrv/sites/gabriel/public_html”

Apache va refuza să difuzeze conținutul, deoarece index.html a fost etichetat cu tipul default_t SELinux, pe care Apache nu îl poate accesa:

# wget http://localhost/index.html
# ls -lZ /websrv/sites/gabriel/public_html/index.html

Ca și în exemplul anterior, puteți utiliza următoarea comandă pentru a verifica dacă aceasta este într-adevăr o problemă legată de SELinux:

# cat /var/log/audit/audit.log | grep AVC | tail -1

Pentru a schimba recursiv eticheta /websrv/sites/gabriel/public_html la httpd_sys_content_t, procedați:

# semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

Comanda de mai sus va acorda Apache acces numai în citire la acel director și la conținutul acestuia.

În cele din urmă, pentru a aplica politica (și a face schimbarea etichetei în vigoare imediat), procedați:

# restorecon -R -v /websrv/sites/gabriel/public_html

Acum ar trebui să puteți accesa directorul:

# wget http://localhost/index.html

Pentru mai multe informații despre SELinux, consultați ghidul Fedora 22 SELinux și administrator.