SELinux (Security-Enhanced Linux): a Linux kernel biztonsági moduljának szerepe

A modern informatikai rendszerek biztonsága napjainkban kritikusabb, mint valaha. A kibertámadások egyre kifinomultabbá válnak, és a hagyományos védelmi mechanizmusok, mint például a felhasználói jogosultságok (Discretionary Access Control – DAC) alapú rendszerek, sokszor már nem nyújtanak elegendő védelmet. Ebben a komplex és folyamatosan változó környezetben válik kulcsfontosságúvá az operációs rendszerek mélyebb szintű biztonsági rétegeinek megléte. A Linux rendszerek esetében az egyik legrobosztusabb és legátfogóbb ilyen megoldás az SELinux, azaz a Security-Enhanced Linux.

Az SELinux nem csupán egy kiegészítő eszköz, hanem egy olyan biztonsági architektúra, amely a Linux kernelbe integrálva működik, lehetővé téve a kötelező hozzáférés-vezérlést (Mandatory Access Control – MAC). Míg a DAC rendszerekben a fájl vagy erőforrás tulajdonosa dönthet arról, hogy ki férhet hozzá az adatokhoz, addig a MAC rendszerekben a hozzáférési döntéseket egy központi biztonsági szabályzat hozza meg, függetlenül a felhasználó vagy a folyamat akaratától. Ez a paradigmaváltás alapvetően erősíti meg a rendszer ellenálló képességét a jogosulatlan hozzáférésekkel és a potenciális kihasználásokkal szemben.

A hagyományos Linux biztonsági modell korlátai és a MAC szükségessége

A hagyományos Linux rendszerek alapvetően a Discretionary Access Control (DAC) modellre épülnek. Ez azt jelenti, hogy minden fájlnak és könyvtárnak van egy tulajdonosa, és az ő joga eldönteni, hogy ki olvashatja, írhatja vagy futtathatja az adott erőforrást. A jogosultságokat klasszikusan a felhasználó (user), a csoport (group) és mások (others) kategóriákra osztva, a rwx (read, write, execute) bitekkel lehet beállítani. Emellett léteznek speciális bitek, mint az SUID (Set User ID), a SGID (Set Group ID) és a Sticky bit, amelyek további funkciókat biztosítanak, például egy program futtatásakor annak a tulajdonosának jogosultságaival való ideiglenes öröklését.

Bár a DAC modell egyszerű és rugalmas, jelentős biztonsági hiányosságokkal rendelkezik, különösen egy kompromittált folyamat vagy felhasználói fiók esetében. Ha egy alkalmazás sérülékeny, és egy támadó képes kódot futtatni annak kontextusában, akkor az alkalmazás minden jogosultságát örökli. Ha például egy webkiszolgáló folyamat (pl. Apache) valamilyen okból sérülékennyé válik, és root jogosultságokkal fut (ami ritka, de előfordulhat hibás konfiguráció esetén), akkor a támadó teljes hozzáférést szerezhet az egész rendszerhez. De még akkor is, ha alacsonyabb jogosultságokkal fut, képes lehet a számára hozzáférhető fájlok módosítására vagy olvasására, ami adatlopáshoz vagy további támadásokhoz vezethet.

Itt jön képbe a Mandatory Access Control (MAC). A MAC rendszerben a hozzáférési döntéseket nem a felhasználó vagy az erőforrás tulajdonosa hozza meg, hanem egy központi, előre definiált biztonsági szabályzat érvényesíti. Ez a szabályzat minden egyes műveletet felülvizsgál, legyen szó fájlhozzáférésről, hálózati kommunikációról vagy folyamatok közötti interakcióról. A lényeg, hogy még egy root jogosultságokkal rendelkező felhasználó vagy folyamat sem lépheti át a MAC által meghatározott korlátokat, ha a szabályzat tiltja azt. Ez a képesség teszi a MAC-ot rendkívül hatékony eszközzé a rendszer integritásának és bizalmasságának megőrzésében, még akkor is, ha egy része már kompromittálódott.

„Az SELinux a Linux kernelbe integrált kötelező hozzáférés-vezérlési rendszer, amely egy szigorúbb és részletesebb biztonsági modellt valósít meg, mint a hagyományos DAC, megakadályozva a jogosulatlan interakciókat még root jogosultság esetén is.”

A MAC rendszerek bevezetése tehát elsősorban a „defense in depth”, azaz a rétegzett védelem elvének megerősítését szolgálja. Ha az első védelmi vonal (pl. tűzfal, jelszavak) áttörésre kerül, a MAC még mindig korlátozhatja a támadó mozgásterét, megakadályozva a rendszer egészének kompromittálását vagy a kritikus adatok elérését. Ez különösen fontos a szerver környezetekben, ahol számos szolgáltatás futhat, és egyetlen sérülékenység katasztrofális következményekkel járhat.

Az SELinux eredete és alapelvei

Az SELinux története a Nemzetbiztonsági Ügynökség (National Security Agency – NSA) nevéhez fűződik, amely az 1990-es évek végén kezdett el dolgozni egy olyan projekten, amely a UNIX rendszerek biztonságát hivatott megerősíteni. A cél egy rugalmas és kiterjeszthető biztonsági architektúra létrehozása volt, amely képes a kötelező hozzáférés-vezérlés megvalósítására. Ebből a kutatásból született meg a Flask nevű architektúra, amely alapvető elveit tekintve a mai SELinux magját képezi.

A Flask-et később a Red Hat és más közreműködők segítségével integrálták a Linux kernelbe, és 2003-ban hivatalosan is bekerült a 2.6-os Linux kernelbe. Azóta folyamatosan fejlődik, és számos disztribúció, mint például a Red Hat Enterprise Linux (RHEL), CentOS, Fedora, és mások, alapértelmezés szerint engedélyezve szállítják, hangsúlyozva annak fontosságát a modern szerverbiztonságban.

Az SELinux működésének alapja a címkézés (labeling). Minden objektum a rendszerben – legyen szó fájlról, könyvtárról, folyamatról, portról, vagy akár egy hálózati interfészről – kap egy biztonsági kontextust (security context), egy egyedi azonosítót. Ez a kontextus több részből áll, de a legfontosabb eleme a típus (type). A típus határozza meg, hogy az adott objektum milyen kategóriába tartozik, és milyen műveleteket végezhet vagy végezhetnek rajta. Például egy webkiszolgáló fájljai a httpd_sys_content_t típust kaphatják, míg a webkiszolgáló folyamata a httpd_t típust.

A biztonsági döntéseket egy szabályzat (policy) alapján hozza meg a rendszer. Ez a szabályzat egy sor szabályból áll, amelyek meghatározzák, hogy egy bizonyos típusú alany (subject, pl. egy folyamat) milyen műveletet (action) hajthat végre egy bizonyos típusú objektumon (object, pl. egy fájl). Például egy szabály kimondhatja, hogy a httpd_t típusú folyamat olvashatja a httpd_sys_content_t típusú fájlokat, de nem írhatja azokat.

Az SELinux három alapvető hozzáférés-vezérlési modellt támogat:

1. Típus-alapú kényszerítés (Type Enforcement – TE): Ez a leggyakrabban használt és legfontosabb modell. Minden objektumhoz és alanyhoz egy típust rendel, és a szabályok meghatározzák, hogy mely típusok interakciója engedélyezett. Ez rendkívül finom szemcséjű vezérlést tesz lehetővé.
2. Szerep-alapú hozzáférés-vezérlés (Role-Based Access Control – RBAC): Az RBAC lehetővé teszi, hogy a felhasználókhoz szerepeket rendeljünk, és ezek a szerepek határozzák meg, hogy a felhasználó milyen típusú folyamatokat indíthat el. Például egy rendszergazdai szerep (staff_r) több jogosultságot biztosíthat, mint egy átlagos felhasználói szerep (user_r).
3. Többszintű biztonság (Multi-Level Security – MLS) és Többkategóriás biztonság (Multi-Category Security – MCS): Ezek a modellek érzékenységi szintek és kategóriák alapján korlátozzák a hozzáférést. Az MLS a „titkosított” vagy „szigorúan titkos” jellegű adatok védelmére szolgál, míg az MCS a különböző projektcsoportok vagy ügyfelek adatainak elkülönítésére. Ezeket jellemzően magas biztonsági igényű környezetekben használják.

Az SELinux ereje abban rejlik, hogy a szabályokat a Linux kernel szintjén érvényesíti, még a hagyományos DAC jogosultságok ellenőrzése előtt. Ez azt jelenti, hogy még egy root felhasználó sem tud olyan műveletet végrehajtani, amelyet az SELinux szabályzat tilt, hacsak nem módosítja a szabályzatot, ami önmagában is egy védett művelet.

Az SELinux architektúrája és működése

Az SELinux nem egy önálló alkalmazás, hanem a Linux kernel szerves része, amely a biztonsági döntések meghozataláért és érvényesítéséért felelős. Működésének megértéséhez érdemes áttekinteni a főbb komponenseit és azok interakcióját.

A biztonsági kontextusok és címkézés

Minden SELinux által védett objektum és alany egy biztonsági kontextussal rendelkezik. Ez a kontextus egy karakterlánc, amely általában négy részből áll:

felhasználó:szerep:típus:érzékenység[:kategória]

• Felhasználó (user): Ez egy SELinux felhasználó, nem feltétlenül azonos a Linux felhasználóval. Például unconfined_u vagy system_u.
• Szerep (role): Meghatározza, hogy az adott SELinux felhasználó milyen szerepet tölthet be, és milyen típusú folyamatokat indíthat el. Például object_r (objektumokhoz) vagy system_r (rendszerfolyamatokhoz).
• Típus (type): Ez a legfontosabb elem. Meghatározza az objektum vagy folyamat funkcióját, és ez alapján dönti el az SELinux, hogy milyen műveleteket engedélyez vagy tilt. Például httpd_t (Apache folyamat), var_log_t (naplófájl), httpd_sys_content_t (weboldal tartalma).
• Érzékenység (sensitivity) és Kategória (category): Ezek az MLS/MCS modellekhez tartoznak. Például s0 (alacsony érzékenység) vagy s0:c0.c1023 (érzékenység és kategóriák).

Például, ha egy Apache webkiszolgáló folyamatot vizsgálunk, annak kontextusa lehet system_u:system_r:httpd_t:s0. Ez azt jelenti, hogy egy rendszer felhasználó futtatja, a rendszer szerepkörben, egy Apache típusú folyamatként, alapértelmezett érzékenységi szinten.

A fájlok és könyvtárak esetén a kontextusok a fájlrendszerben tárolódnak (általában az extended attributes – xattrs segítségével). Amikor egy folyamat hozzáfér egy fájlhoz, az SELinux kernel modul összehasonlítja a folyamat kontextusát a fájl kontextusával és a betöltött szabályzattal, hogy eldöntse, engedélyezi-e a műveletet.

A biztonsági szabályzat (Security Policy)

Az SELinux szíve a biztonsági szabályzat. Ez egy gyűjteménye a szabályoknak, amelyek meghatározzák, hogy mely típusok interakciója engedélyezett. A szabályzatot egy speciális nyelven írják (korábban TE – Type Enforcement nyelv, ma már inkább CIL – Common Intermediate Language), majd lefordítják egy bináris formátumba, amelyet a kernel képes betölteni és értelmezni.

A szabályzat rendkívül részletes lehet, és kiterjedhet szinte minden rendszerhívásra, beleértve a fájlműveleteket (olvasás, írás, futtatás), a hálózati kommunikációt (portok elérése, csatlakozás), a folyamatok közötti kommunikációt (IPC), és még sok mást. Például, egy szabály így nézhet ki (egyszerűsítve):

allow httpd_t httpd_sys_content_t:file { read getattr map };

Ez a szabály engedélyezi a httpd_t típusú folyamatoknak, hogy olvassák, attribútumokat kérdezzenek le, és memóriába képezzék (map) a httpd_sys_content_t típusú fájlokat. Ha valaki megpróbálja írni ezeket a fájlokat, az SELinux megtagadja a műveletet, még akkor is, ha a hagyományos DAC jogosultságok engedélyeznék.

A szabályzatok rendkívül komplexek lehetnek, és a disztribúciók általában előre konfigurált, jól tesztelt szabályzatokkal érkeznek (pl. a targeted policy, ami a legtöbb szolgáltatást védi). A rendszergazdáknak ritkán kell a teljes szabályzatot kézzel szerkeszteniük; ehelyett booleane-eket (boolean flags) használnak, amelyek lehetővé teszik a szabályzat bizonyos részeinek dinamikus engedélyezését vagy tiltását, vagy egyedi szabályok hozzáadását a semodule paranccsal.

A biztonsági szerver és az AVC

Amikor egy folyamat megpróbál egy műveletet végrehajtani (pl. fájlt nyit meg), a Linux kernel továbbítja a kérést az SELinux biztonsági szervernek. A szerver a kérésben szereplő alany (folyamat) és objektum (fájl) biztonsági kontextusát, valamint a kért műveletet felhasználva lekérdezi a betöltött szabályzatot, hogy engedélyezett-e a művelet. A szerver ezután egy döntést (döntési vektor) ad vissza a kernelnek: engedélyezés (allow) vagy megtagadás (deny).

A teljesítmény optimalizálása érdekében az SELinux egy Access Vector Cache (AVC)-t használ. Ez egy gyorsítótár, amely tárolja a korábbi biztonsági döntéseket. Ha egy folyamat ismételten hozzáfér ugyanahhoz az objektumhoz, a döntés az AVC-ből kerül lekérésre, elkerülve a szabályzat ismételt kiértékelését. Ha az AVC-ben nincs találat, a biztonsági szerver kiértékeli a szabályzatot, és az eredményt elmenti az AVC-be a későbbi használatra.

„Az SELinux minden egyes rendszerhívást felügyel, és a biztonsági kontextusok, valamint a központi szabályzat alapján dönt a hozzáférésről, biztosítva a finom szemcséjű vezérlést és a rétegzett védelmet.”

Ha egy műveletet az SELinux megtagad, az egy AVC denial eseményt generál. Ez az esemény bekerül a kernel naplójába, és az auditd démon (auditálás démon) által kezelt audit naplófájlokba (általában /var/log/audit/audit.log). Ezek a naplók kulcsfontosságúak az SELinux hibakereséséhez és a szabályzat finomhangolásához.

SELinux módok és kezelésük

Az SELinux három fő üzemmódban működhet, amelyek befolyásolják, hogyan érvényesíti a biztonsági szabályzatot:

1. Kényszerítő mód (Enforcing mode)

Ez a legbiztonságosabb és javasolt üzemmód. Az SELinux ebben a módban aktívan érvényesíti a szabályzatot. Minden olyan műveletet, amelyet a szabályzat tilt, az SELinux azonnal blokkol, és egy AVC denial eseményt naplóz. Ez az üzemmód biztosítja a legmagasabb szintű védelmet, de hibás konfiguráció esetén szolgáltatáskimaradást okozhat, ha a szükséges műveleteket is tiltja.

2. Megengedő mód (Permissive mode)

Ebben a módban az SELinux nem érvényesíti a szabályzatot, de továbbra is naplózza azokat a műveleteket, amelyeket a szabályzat egyébként megtiltana. Ez az üzemmód rendkívül hasznos a hibakereséshez és az új alkalmazások telepítéséhez. Amikor egy szolgáltatás nem működik megfelelően, és gyanítható az SELinux szerepe, érdemes megengedő módba kapcsolni, és megfigyelni a naplókat. Ha a szolgáltatás elindul, de a naplókban megjelennek a „denied” üzenetek, az azt jelenti, hogy az SELinux szabályzat finomhangolásra szorul.

3. Letiltott mód (Disabled mode)

Ebben a módban az SELinux teljesen inaktív. Nem érvényesít szabályokat, és nem is naplóz semmit. Ez a legkevésbé biztonságos üzemmód, és általánosan nem ajánlott éles környezetekben. A letiltott módból való visszaváltás kényszerítő vagy megengedő módba gyakran megköveteli a teljes fájlrendszer újra címkézését, ami időigényes folyamat lehet.

Az SELinux módok kezelése

Az aktuális SELinux üzemmód lekérdezéséhez a getenforce parancsot használhatjuk:

$ getenforce
Enforcing

Az üzemmód ideiglenes megváltoztatásához (újraindításig érvényes) a setenforce parancsot használhatjuk.
Megengedő módba kapcsolás:

$ sudo setenforce 0

Kényszerítő módba kapcsolás:

$ sudo setenforce 1

Az üzemmód tartós megváltoztatásához (az újraindítás után is érvényes) a /etc/selinux/config fájlt kell szerkeszteni. Keresse meg az SELINUX= sort, és módosítsa az értékét enforcing, permissive vagy disabled értékre:

# 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 these two values:
#       targeted - Targeted processes are protected,
#                  others are left unconfined.
#       mls      - Multi Level Security protection.
SELINUXTYPE=targeted

A változtatások érvénybe lépéséhez a rendszer újraindítása szükséges.

Fájlrendszer címkézés és kontextusok kezelése

Az SELinux egyik alapvető feladata a fájlrendszer objektumainak (fájlok, könyvtárak, eszközök) megfelelő biztonsági kontextussal való ellátása. Ez a címkézés kulcsfontosságú, mivel az SELinux szabályzatok a kontextusok alapján hozzák meg a döntéseket. Ha egy fájl hibás kontextussal rendelkezik, az SELinux megtagadhatja a hozzáférést még akkor is, ha a hagyományos jogosultságok engedélyeznék.

Kontextusok megtekintése

A fájlok és könyvtárak SELinux kontextusát az ls -Z paranccsal tekinthetjük meg:

$ ls -Z /var/www/html/index.html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

Ez a kimenet mutatja, hogy az index.html fájl httpd_sys_content_t típusú kontextussal rendelkezik, ami jellemzően a webkiszolgáló által szolgáltatott statikus tartalomhoz tartozik.

Folyamatok kontextusát a ps -Z paranccsal ellenőrizhetjük:

$ ps -Z aux | grep httpd
system_u:system_r:httpd_t:s0 root     1234  0.0  0.1 200000 5000 ?        Ss   10:00   0:00 /usr/sbin/httpd -DFOREGROUND

Ez jelzi, hogy az Apache folyamat httpd_t típusú kontextusban fut.

Kontextusok módosítása: chcon

Az chcon parancs lehetővé teszi egy fájl vagy könyvtár SELinux kontextusának ideiglenes megváltoztatását. Ez a változtatás azonban nem tartós, azaz a fájlrendszer újra címkézésekor (pl. restorecon futtatásakor vagy újraindításkor) visszaáll az eredeti, a szabályzat által meghatározott kontextusra. Ezért elsősorban hibakeresésre vagy ideiglenes megoldásokra használják.

# Példa: Egy fájl típusának megváltoztatása
$ sudo chcon -t httpd_sys_content_t /opt/mywebapp/index.html

A -R kapcsolóval rekurzívan is módosíthatók a kontextusok egy könyvtáron belül.

Kontextusok visszaállítása: restorecon

A restorecon parancs a leggyakrabban használt eszköz a fájlrendszer címkézésének kezelésére. Ez a parancs visszaállítja a fájlok és könyvtárak SELinux kontextusát a szabályzat által előre definiált értékekre. Ez akkor hasznos, ha valamilyen okból (pl. manuális másolás, hibás konfiguráció) egy fájl kontextusa megváltozott, és vissza kell állítani az alapértelmezettre.

# Egy fájl kontextusának visszaállítása
$ sudo restorecon /var/www/html/my_new_file.html

# Egy könyvtár és annak tartalmának rekurzív visszaállítása
$ sudo restorecon -Rv /var/www/html/

A restorecon a fájlkontextus szabályok (file context rules) alapján működik, amelyeket a betöltött SELinux szabályzat tartalmaz. Ezek a szabályok reguláris kifejezések segítségével rendelik hozzá a kontextusokat a fájlrendszer bizonyos útvonalaihoz.

Tartós fájlkontextus szabályok kezelése: semanage fcontext

Ha egy olyan könyvtárba szeretnénk fájlokat elhelyezni, amelynek alapértelmezett SELinux kontextusa nem megfelelő a céljainknak (pl. egy egyedi webes alkalmazás könyvtára), akkor tartós fájlkontextus szabályokat kell létrehoznunk. Ezt a semanage fcontext paranccsal tehetjük meg.

# Példa: Egy új webalkalmazás könyvtárának beállítása
# Hozzáadunk egy szabályt, amely a /srv/mywebapp könyvtár és annak tartalmára vonatkozik
$ sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mywebapp(/.*)?"

# Ezután futtatjuk a restorecon-t, hogy a szabály érvénybe lépjen a fájlokon
$ sudo restorecon -Rv /srv/mywebapp/

A -a kapcsoló hozzáad egy új szabályt, a -t megadja a céltípust (target type), és a reguláris kifejezés "/srv/mywebapp(/.*)?" biztosítja, hogy a szabály a könyvtárra és az összes alatta lévő fájlra is érvényes legyen. A semanage fcontext csak a szabályt adja hozzá a rendszerhez, de a tényleges címkézéshez mindig szükség van a restorecon futtatására.

A meglévő fájlkontextus szabályokat a semanage fcontext -l paranccsal listázhatjuk.

A fájlrendszer címkézésének helyes kezelése alapvető fontosságú az SELinux hatékony működéséhez. A legtöbb SELinux-szal kapcsolatos probléma abból adódik, hogy a fájlok nem a megfelelő kontextussal rendelkeznek, ami megakadályozza a szolgáltatások hozzáférését.

SELinux hibakeresés és a naplók elemzése

Az SELinux bevezetése vagy egy új szolgáltatás konfigurálása során gyakori, hogy a rendszer megtagadja a hozzáférést, és a szolgáltatás nem működik megfelelően. Ilyenkor a naplók elemzése kulcsfontosságú a probléma azonosításához és megoldásához. Az SELinux az auditd démonon keresztül naplózza az összes megtagadott műveletet.

Az audit naplók helye és megtekintése

Az SELinux által generált események (különösen az AVC denial-ek) az audit rendszer naplóiba kerülnek, amelyek általában a /var/log/audit/audit.log fájlban találhatók. Ezek a naplók részletes információt tartalmaznak a megtagadott műveletekről.

A naplók megtekintéséhez használhatjuk a tail -f /var/log/audit/audit.log parancsot, vagy a journalctl parancsot a _COMM vagy _SELINUX_AVC mezők szűrésével.

$ sudo tail -f /var/log/audit/audit.log

Egy tipikus AVC denial bejegyzés rendkívül részletes, és számos mezőt tartalmaz, amelyek segítenek a probléma megértésében:

type=AVC msg=audit(1678886400.000:123): avc:  denied  { write } for  pid=456 comm="httpd" name="web_log.log" dev="dm-0" ino=789 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0

Ennek a bejegyzésnek a kulcsfontosságú részei:

• type=AVC: Jelzi, hogy ez egy SELinux hozzáférés-vezérlési esemény.
• denied { write }: A megtagadott művelet (ebben az esetben írás).
• pid=456 comm="httpd": A folyamat azonosítója és neve, amely megpróbálta a műveletet végrehajtani.
• name="web_log.log": Az objektum neve.
• scontext=system_u:system_r:httpd_t:s0: Az alany (folyamat) biztonsági kontextusa. Itt a httpd_t a fontos.
• tcontext=system_u:object_r:var_log_t:s0: A cél (objektum) biztonsági kontextusa. Itt a var_log_t a fontos.
• tclass=file: Az objektum típusa (ebben az esetben fájl).
• permissive=0: Jelzi, hogy kényszerítő módban történt a megtagadás (1 lenne megengedő módban).

Ez a példa azt mutatja, hogy az Apache folyamat (httpd_t) megpróbált írni egy naplófájlba (web_log.log), amelynek kontextusa var_log_t. A standard SELinux szabályzat nem engedélyezi, hogy a webkiszolgáló írjon a generikus naplófájl könyvtárba, mert az a rendszer integritását veszélyeztetné. Ehelyett a webkiszolgálóknak a saját naplókönyvtárukba (pl. /var/log/httpd/, amelynek kontextusa httpd_log_t) kell írniuk.

A sealert eszköz

Az audit naplók manuális értelmezése időigényes és bonyolult lehet, különösen, ha sok denial van. Erre a célra fejlesztették ki a sealert eszközt, amely az audit2allow csomag része. A sealert automatikusan elemzi az audit naplókat, és felhasználóbarát formában jeleníti meg az SELinux problémákat, javaslatokat téve a megoldásra.

$ sudo sealert -a /var/log/audit/audit.log

A sealert kimenete sokkal könnyebben értelmezhető, mint a nyers audit log. Gyakran javasolja a fájlkontextus módosítását (chcon vagy restorecon) vagy egy SELinux boolean engedélyezését. Ha egyik sem segít, akkor a audit2allow használatát javasolja egy egyedi szabály létrehozásához.

Az audit2allow eszköz

Ha a sealert nem kínál egyszerű megoldást, és meggyőződtünk arról, hogy a megtagadott művelet valóban szükséges és biztonságos, akkor az audit2allow paranccsal létrehozhatunk egy egyedi SELinux szabályt (local policy module). Ez az eszköz az audit naplókból generál egy .te (Type Enforcement) fájlt, amelyet aztán lefordíthatunk egy .pp (Policy Package) fájllá, és betölthetünk a rendszerbe.

# 1. Kinyerjük a releváns denial-eket az audit logból egy temp fájlba
$ grep "AVC" /var/log/audit/audit.log | tail -n 50 > /tmp/mylog

# 2. Generálunk egy .te fájlt az audit2allow segítségével
$ sudo audit2allow -a /tmp/mylog -M mycustompolicy

Ez a parancs két fájlt hoz létre: mycustompolicy.te és mycustompolicy.fc (fájlkontextus szabályok, ha szükséges). A .te fájl tartalmazza az új allow szabályokat. Fontos, hogy alaposan ellenőrizzük a generált .te fájl tartalmát, hogy ne adjunk túl széles jogosultságokat, ami biztonsági rést okozhat.

# 3. Lefordítjuk és betöltjük a modult
$ sudo semodule -i mycustompolicy.pp

A semodule -i parancs lefordítja a .te fájlt .pp formátumba és betölti a modult a futó SELinux szabályzatba. Ezzel a módszerrel finomhangolhatjuk az SELinux viselkedését anélkül, hogy letiltanánk azt, vagy módosítanánk a disztribúció alapértelmezett szabályzatát.

A hibakeresés során érdemes a következő lépéseket követni:

1. Próbálja meg reprodukálni a problémát.
2. Kapcsolja az SELinux-ot permissive módba (sudo setenforce 0).
3. Próbálja újra a műveletet. Ha most működik, az SELinux okozza a problémát.
4. Ellenőrizze az audit naplókat (sudo sealert -a /var/log/audit/audit.log vagy sudo ausearch -m AVC -ts today).
5. Keressen javaslatokat a sealert kimenetében. Gyakran elegendő egy fájlkontextus visszaállítása (restorecon) vagy egy boolean engedélyezése (setsebool).
6. Ha a sealert nem segít, elemezze a nyers AVC denial üzeneteket, és ha szükséges, hozzon létre egy egyedi szabályt az audit2allow segítségével, de csak óvatosan és alapos ellenőrzés után.
7. Miután a probléma megoldódott, kapcsolja vissza az SELinux-ot enforcing módba (sudo setenforce 1).

SELinux booleane-ek és szerepük

Az SELinux szabályzatok rendkívül részletesek és komplexek. Gyakran előfordul, hogy egy adott szolgáltatás vagy funkció működéséhez szükség van egy kis eltérésre az alapértelmezett szabályzattól. Ahelyett, hogy minden ilyen esetben egyedi szabályokat írnánk, az SELinux bevezette a booleane-ek (boolean flags) koncepcióját.

Az SELinux booleane-ek olyan kapcsolók, amelyek lehetővé teszik a szabályzat bizonyos részeinek dinamikus engedélyezését vagy tiltását anélkül, hogy újra kellene fordítani vagy betölteni a teljes szabályzatot. Ezek a booleane-ek előre definiáltak a disztribúciók által szállított szabályzatokban, és jellemzően olyan gyakori forgatókönyveket fednek le, mint például a webkiszolgáló hozzáférése a felhasználói home könyvtárakhoz, vagy az FTP szerver írási jogosultságai.

Booleane-ek listázása és állapotuk ellenőrzése

Az összes elérhető SELinux boolean listázásához és aktuális állapotuk (on/off) megtekintéséhez használjuk a getsebool -a parancsot:

$ getsebool -a | grep httpd
httpd_anon_write --> off
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_sendmail --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_unified_parent --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_nfs --> off
httpd_builtin_scripting --> on
httpd_dbus_sssd --> off
httpd_mod_auth_ntlm_winbind --> off
httpd_ssi_exec --> off
httpd_verify_dns --> off

A kimenet minden boolean nevét és az aktuális állapotát mutatja (on vagy off). A nevek gyakran önmagukért beszélnek, például a httpd_enable_homedirs boolean valószínűleg azt szabályozza, hogy a webkiszolgáló hozzáférhet-e a felhasználók home könyvtáraihoz.

Booleane-ek módosítása: setsebool

A setsebool paranccsal módosíthatjuk egy boolean aktuális állapotát. Fontos megkülönböztetni az ideiglenes és a tartós módosítást.

Ideiglenes módosítás (az újraindításig érvényes)

# Engedélyezzük a webkiszolgálónak a felhasználói home könyvtárak elérését
$ sudo setsebool httpd_enable_homedirs on

Ez a változtatás azonnal életbe lép, de a rendszer újraindításakor visszaáll az eredeti állapotra.

Tartós módosítás (az újraindítás után is érvényes)

Ahhoz, hogy a boolean állapota tartósan megmaradjon, a -P (persistent) kapcsolót kell használnunk:

# Engedélyezzük tartósan a webkiszolgálónak a felhasználói home könyvtárak elérését
$ sudo setsebool -P httpd_enable_homedirs on

Ez a parancs nemcsak az aktuális állapotot változtatja meg, hanem frissíti a szabályzatot is, így a beállítás a rendszer újraindítása után is érvényes marad.

Példa a boolean használatára: Ha egy webkiszolgáló (Apache) szeretne tartalmat szolgáltatni a felhasználók home könyvtáraiból (pl. /home/user/public_html), akkor az alapértelmezett SELinux szabályzat ezt megtiltja, mert a httpd_t típusú folyamatoknak nincs engedélyük hozzáférni a user_home_dir_t típusú könyvtárakhoz. Ezt a problémát a httpd_enable_homedirs boolean engedélyezésével orvosolhatjuk:

$ sudo setsebool -P httpd_enable_homedirs on

Ezután győződjünk meg arról, hogy a felhasználó home könyvtárában lévő public_html könyvtár és annak tartalma rendelkezik a megfelelő SELinux kontextussal (általában httpd_user_content_t). Ezt a restorecon paranccsal állíthatjuk be:

$ sudo restorecon -Rv /home/user/public_html

A booleane-ek használata sokkal egyszerűbb és biztonságosabb, mint egyedi szabályok írása, mivel ezeket a kapcsolókat a disztribúció fejlesztői már előre tesztelték és validálták. Mindig érdemes először megvizsgálni, hogy van-e megfelelő boolean a problémára, mielőtt bonyolultabb, egyedi szabályzatmodulok fejlesztésébe kezdenénk.

SELinux és a konténerizáció (Docker, Podman)

A konténerizáció, különösen a Docker és Podman használata forradalmasította az alkalmazások telepítését és futtatását. Bár a konténerek alapvetően elszigeteltek a gazdagéptől, mégis kritikus fontosságú a megfelelő biztonsági rétegek alkalmazása, és az SELinux itt is kulcsszerepet játszik. A legtöbb modern Linux disztribúcióban, mint például a Red Hat Enterprise Linux, CentOS vagy Fedora, az SELinux alapértelmezés szerint engedélyezve van, és szorosan integrálódik a konténer futtatókörnyezetekkel.

Konténer biztonság SELinux-szal

A konténerek önmagukban processzus-szintű elszigetelést biztosítanak a névterek (namespaces) és a cgroups (control groups) segítségével. Azonban egy konténerből való kitörés (container escape) továbbra is lehetséges, ha a kernelben vagy a konténer futtatókörnyezetben sérülékenység található. Itt jön képbe az SELinux, mint egy további, erőteljes védelmi vonal.

Az SELinux a konténerek esetében is a címkézés elvén működik. A konténer folyamatok, a konténer lemezképek, a tárolt adatok és a gazdagép fájlrendszerének bizonyos részei mind speciális SELinux kontextust kapnak. Ez a kontextus korlátozza a konténer által végezhető műveleteket, még akkor is, ha a konténeren belül a root felhasználóval futtatunk folyamatokat.

A Docker és Podman alapértelmezés szerint a container_t vagy container_runtime_t típusú kontextusban futtatja a konténer folyamatokat, és a konténer tárolókönyvtárai (pl. /var/lib/docker vagy /var/lib/containers) speciális, konténer-specifikus típusokkal rendelkeznek (pl. container_var_lib_t). Ezek a típusok biztosítják, hogy:

• Egy konténer folyamat ne férhessen hozzá a gazdagép érzékeny fájljaihoz.
• Egy konténer ne módosíthassa más konténerek adatait.
• A gazdagép más folyamatai ne férhessenek hozzá a konténer belső adataihoz.

Közös problémák és megoldások

A leggyakoribb SELinux probléma konténerekkel kapcsolatban akkor merül fel, amikor a gazdagép fájlrendszeréből volume-okat (kötéseket) csatolunk a konténerbe. Ha a gazdagép könyvtárának SELinux kontextusa nem megfelelő, a konténerben futó alkalmazás nem fogja tudni elérni a fájlokat.

Például, ha egy Nginx konténernek szüksége van a /srv/mywebapp könyvtár tartalmára a gazdagépen, és ezt a könyvtárat volume-ként csatoljuk:

$ docker run -d -p 80:80 -v /srv/mywebapp:/usr/share/nginx/html nginx

Ha a /srv/mywebapp könyvtár kontextusa például default_t, akkor az Nginx konténer folyamat (amely container_t vagy container_file_t kontextusban fut) valószínűleg nem fogja tudni olvasni a fájlokat. Az audit naplókban AVC denied üzenetek jelennének meg.

A megoldás a volume címkézésének helyes beállítása. Két fő opció létezik:

1. :z opció (Docker): Ez az opció azt jelzi a Dockernek, hogy a kötet privát, nem megosztott tartalommal rendelkezik, és a futtatókörnyezetnek automatikusan be kell állítania a megfelelő SELinux címkézést a konténer számára. Ez általában container_file_t típust jelent, és megengedővé teszi a konténer számára a hozzáférést.

   $ docker run -d -p 80:80 -v /srv/mywebapp:/usr/share/nginx/html:z nginx

   A :z opcióval a Docker automatikusan container_file_t kontextust ad a /srv/mywebapp könyvtárnak és annak tartalmának. Ez a kontextus csak az adott konténer számára engedélyezi a hozzáférést.

2. :Z opció (Docker): Hasonló a :z-hez, de ez az opció azt jelzi, hogy a kötet megosztott tartalommal rendelkezik, és a futtatókörnyezetnek egyedi, nem megosztott címkézést kell alkalmaznia. Ez jellemzően akkor hasznos, ha a gazdagép könyvtárát több konténer is használja, és mindegyiknek saját, elszigetelt hozzáférésre van szüksége. Azonban ritkábban használt, és óvatosan kell alkalmazni.
3. Manuális címkézés semanage fcontext-tel: Ez a legbiztonságosabb és legátláthatóbb módszer. Ezzel a módszerrel tartósan beállíthatjuk a gazdagép könyvtárának SELinux kontextusát egy olyan típusra, amelyhez a konténer folyamatnak van engedélye. Például a webes tartalomhoz:

   $ sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mywebapp(/.*)?"
   $ sudo restorecon -Rv /srv/mywebapp/
   $ docker run -d -p 80:80 -v /srv/mywebapp:/usr/share/nginx/html nginx

   Ebben az esetben a /srv/mywebapp és tartalma a httpd_sys_content_t típust kapja, amihez a container_t típusú konténer folyamat (az Nginx) alapértelmezés szerint hozzáfér, ha a policy ezt engedélyezi. Ez a módszer előnyösebb, ha a volume-ot egy specifikus szolgáltatás (pl. webkiszolgáló) számára csatoljuk, és szeretnénk, ha a tartalom kontextusa egyértelműen tükrözné annak rendeltetését.

A Podman esetében a volume címkézés hasonlóan működik, és a :z és :Z opciók is elérhetők. A Podman emellett alapértelmezetten rootless konténerek futtatását is támogatja, ami további biztonsági réteget ad hozzá, és az SELinux továbbra is érvényesíti a szabályokat ezen a szinten is.

Az SELinux kulcsfontosságú a konténeres környezetek biztonságában, mivel segít megelőzni a jogosulatlan hozzáféréseket és a privilegium eszkalációt, még akkor is, ha egy konténer vagy a futtatókörnyezet sérülékennyé válik. A helyes címkézés és a szabályzatok megértése elengedhetetlen a biztonságos konténeres infrastruktúra kiépítéséhez.

SELinux és a hálózati szolgáltatások

Az SELinux nem csak a fájlrendszer hozzáférését szabályozza, hanem kiterjed a hálózati kommunikációra is. Ez azt jelenti, hogy az SELinux képes korlátozni, hogy mely folyamatok hallgathatnak bizonyos portokon, és melyek indíthatnak vagy fogadhatnak hálózati kapcsolatokat. Ez egy rendkívül fontos védelmi mechanizmus, amely megakadályozhatja, hogy egy kompromittált szolgáltatás jogosulatlan hálózati műveleteket hajtson végre, vagy rosszindulatú portokat nyisson meg.

Portok címkézése

Az SELinux a hálózati portokat is biztonsági kontextussal címkézi. Ez a kontextus, hasonlóan a fájlkontextushoz, meghatározza, hogy mely folyamatok férhetnek hozzá az adott porthoz. A portok kontextusait a semanage port paranccsal kezelhetjük.

A meglévő port szabályok listázása:

$ sudo semanage port -l | grep http
http_port_t                    tcp      80, 81, 443, 4430, 4433, 8008, 8009, 8443, 9000
http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
...

Ez a kimenet azt mutatja, hogy a http_port_t típusú portok a TCP 80-as, 443-as és más portokhoz vannak rendelve. Az SELinux szabályzat ezután meghatározza, hogy a httpd_t típusú folyamatok hallgathatnak a http_port_t típusú portokon.

Új port szabály hozzáadása

Tegyük fel, hogy az Apache webkiszolgálónkat a standard 80-as port helyett a 8088-as porton szeretnénk futtatni. Ha csak a httpd.conf fájlban módosítjuk a portot, az Apache nem fog tudni elindulni vagy hallgatni a 8088-as porton, mert az SELinux alapértelmezés szerint megtiltja. Az audit naplókban AVC denied { name_bind } üzenetek jelennének meg.

A probléma megoldásához hozzá kell adnunk a 8088-as portot a http_port_t típushoz:

# Hozzáadjuk a 8088-as TCP portot a http_port_t típushoz
$ sudo semanage port -a -t http_port_t -p tcp 8088

A -a kapcsoló hozzáad egy új szabályt, a -t megadja a céltípust, a -p a protokoll típusát (tcp vagy udp), és végül a portszámot.

Ezután az Apache újraindítható, és képes lesz hallgatni a 8088-as porton, mivel az SELinux szabályzat mostantól engedélyezi ezt a műveletet.

Hálózati booleane-ek

A fájlrendszerhez hasonlóan, a hálózati interakciókhoz is léteznek SELinux booleane-ek, amelyek finomhangolják a hálózati hozzáférést a különböző szolgáltatások számára. Néhány példa:

• httpd_can_network_connect: Engedélyezi-e az Apache-nak, hogy kimenő hálózati kapcsolatokat kezdeményezzen. Ez hasznos lehet, ha az Apache egy külső API-val kommunikál.
• httpd_can_network_connect_db: Engedélyezi-e az Apache-nak, hogy adatbázis-kapcsolatot létesítsen egy hálózaton keresztül (pl. MySQL szerverhez egy másik gépen).
• ftp_home_dir: Engedélyezi-e az FTP szervernek, hogy hozzáférjen a felhasználók home könyvtáraihoz.

Ezeket a booleane-eket a setsebool -P paranccsal engedélyezhetjük vagy tilthatjuk, ahogy azt korábban tárgyaltuk.

# Engedélyezzük az Apache-nak a kimenő hálózati kapcsolatokat
$ sudo setsebool -P httpd_can_network_connect on

A hálózati kommunikáció SELinux általi felügyelete rendkívül hatékony védelmet nyújt a szolgáltatások elleni támadásokkal szemben. Például, ha egy webkiszolgáló sérülékennyé válik, és egy támadó megpróbálja azt használni belső hálózat szkennelésére vagy más gépek megtámadására, az SELinux blokkolhatja ezeket a kimenő kapcsolatokat, ha a megfelelő boolean (pl. httpd_can_network_connect) le van tiltva.

SELinux felhasználók és szerepek

Az SELinux nem csak a folyamatok és fájlok közötti interakciókat szabályozza, hanem a felhasználók és a futtatható programok közötti kapcsolatot is. Ez a szerep-alapú hozzáférés-vezérlés (RBAC) modell része, amely lehetővé teszi, hogy a hagyományos Linux felhasználókhoz SELinux felhasználókat és szerepeket rendeljünk. Ezáltal finomabb kontrollt gyakorolhatunk arra, hogy egy adott felhasználó milyen típusú folyamatokat indíthat el, és milyen jogosultságokkal rendelkezik.

SELinux felhasználók és Linux felhasználók

Fontos megérteni, hogy az SELinux felhasználók nem azonosak a Linux felhasználókkal. Egy SELinux felhasználó egy absztrakció, amelyhez egy vagy több Linux felhasználót hozzárendelhetünk. Az SELinux felhasználókhoz szerepeket (roles) rendelünk, és ezek a szerepek határozzák meg, hogy milyen típusú tartományokba (domains) léphetnek be a felhasználók, azaz milyen programokat futtathatnak.

Az alapértelmezett SELinux szabályzatban a leggyakoribb SELinux felhasználók:

• unconfined_u: Ez a felhasználó a legkevésbé korlátozott. A legtöbb interaktív Linux felhasználó ehhez a SELinux felhasználóhoz van rendelve alapértelmezés szerint. Az unconfined_u képes a legtöbb műveletet végrehajtani a rendszeren, és általában csak az SELinux szabályzat legáltalánosabb korlátozásai vonatkoznak rá. A legtöbb rendszergazda és fejlesztő ezzel a felhasználóval dolgozik.
• system_u: Ez a felhasználó a rendszerfolyamatokhoz és szolgáltatásokhoz van rendelve. Ezek a folyamatok szigorúbb korlátozások alá esnek, mint az unconfined_u felhasználó által indított folyamatok.
• guest_u, staff_u, user_u: Ezek specifikusabb felhasználói típusok, amelyekhez szigorúbb vagy specifikusabb szerepek és tartományok rendelhetők.

Szerepek (Roles)

Az SELinux szerepek határozzák meg, hogy egy SELinux felhasználó milyen tartományokba (domains) léphet be. Egy tartomány egy folyamat SELinux típusa. Például, ha egy felhasználó a staff_r szereppel rendelkezik, akkor elindíthatja a sysadm_t tartományban futó programokat, ami lehetővé teszi számára a rendszeradminisztrációs feladatok elvégzését.

Néhány gyakori szerep:

• system_r: Rendszerfolyamatokhoz és szolgáltatásokhoz.
• unconfined_r: A legkevésbé korlátozott szerep, gyakran az unconfined_u felhasználóhoz rendelve.
• staff_r: Rendszergazdai feladatokhoz.
• user_r: Általános felhasználói feladatokhoz.
• object_r: Objektumok (fájlok, könyvtárak) kontextusában használatos.

SELinux login mapping

A Linux felhasználók és az SELinux felhasználók közötti megfeleltetést a login mapping kezeli. Ezt a semanage login paranccsal tekinthetjük meg és módosíthatjuk.

$ sudo 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       *

Ez a kimenet azt mutatja, hogy az alapértelmezett (__default__) és a root Linux felhasználók is az unconfined_u SELinux felhasználóhoz vannak rendelve. Ezért van az, hogy egy root felhasználó is SELinux korlátozások alá eshet, ha a futtatott folyamat típusa korlátozott.

Ha egy új Linux felhasználót hozunk létre, az alapértelmezés szerint az unconfined_u SELinux felhasználóhoz lesz rendelve. Ha egy felhasználó számára szigorúbb biztonsági profilt szeretnénk beállítani, hozzárendelhetjük egy másik SELinux felhasználóhoz és szerephez.

# Hozzárendeljük a "testuser" Linux felhasználót a "user_u" SELinux felhasználóhoz
$ sudo semanage login -a -s user_u testuser

Ezután, amikor a testuser bejelentkezik, az őt képviselő folyamatok a user_u SELinux felhasználói kontextusban fognak futni, és csak az user_r szerep által engedélyezett tartományokba léphetnek be. Ez korlátozhatja, hogy milyen programokat futtathatnak, és milyen erőforrásokhoz férhetnek hozzá, még akkor is, ha a hagyományos Linux jogosultságok egyébként engedélyeznék.

„Az SELinux felhasználók és szerepek finomhangolt kontrollt biztosítanak a Linux felhasználók által indított folyamatok felett, növelve a rendszer biztonságát a felhasználói hibák vagy rosszindulatú tevékenységek ellen.”

run_init és sudo/su kontextusváltás

Amikor egy felhasználó sudo vagy su parancsot használ, az SELinux képes a biztonsági kontextus váltására. Például, ha egy user_u felhasználó sudo-val futtat egy parancsot, az sudo konfigurációja és az SELinux szabályzat alapján a parancs futhat egy staff_t vagy unconfined_t tartományban, ami ideiglenesen emeli a jogosultságokat az SELinux szempontjából.

A run_init boolean például szabályozza, hogy a init folyamat milyen kontextusban futhat, ami kritikus a rendszerindítás során. Az SELinux felhasználók és szerepek kezelése különösen fontos a magas biztonsági igényű környezetekben, ahol a felhasználói jogosultságokat a lehető legszigorúbban kell korlátozni.

Fejlett SELinux koncepciók és használati esetek

Az SELinux képességei messze túlmutatnak az alapvető hozzáférés-vezérlésen. A következő szakaszban néhány fejlettebb koncepciót és specifikus felhasználási esetet tárgyalunk, amelyek rávilágítanak az SELinux rugalmasságára és mélységére.

Multi-Level Security (MLS) és Multi-Category Security (MCS)

Mint korábban említettük, az MLS és MCS modellek az érzékenységi szintek és kategóriák alapján szabályozzák a hozzáférést.

• MLS: Szigorú, hierarchikus biztonsági modell, ahol az információk „titkosított”, „szigorúan titkos” stb. szintekbe sorolhatók. Egy alany csak akkor férhet hozzá egy objektumhoz, ha az alany érzékenységi szintje magasabb vagy egyenlő az objektum érzékenységi szintjével (read-down), és csak alacsonyabb vagy egyenlő érzékenységi szintű objektumokba írhat (write-up), ami megakadályozza az információk szivárgását alacsonyabb szintekre.
• MCS: Nem hierarchikus kategóriákat használ, amelyek lehetővé teszik az adatok elkülönítését különböző projektek vagy osztályok között. Például egy „projekt_A” kategóriába tartozó felhasználó nem férhet hozzá a „projekt_B” kategóriába tartozó adatokhoz, még akkor sem, ha egyébként azonos érzékenységi szinten vannak.

Ezeket a modelleket jellemzően kormányzati, katonai vagy szigorúan szabályozott iparágakban (pl. pénzügyi szektor) alkalmazzák, ahol a legmagasabb szintű adatbiztonságra van szükség.

SELinux Sandbox és sVirt

Az SELinux sandbox egy olyan eszköz, amely lehetővé teszi egy alkalmazás vagy parancs futtatását egy rendkívül korlátozott SELinux kontextusban. Ez ideális lehet olyan ismeretlen vagy potenciálisan veszélyes programok futtatására, amelyek nem igényelnek teljes rendszerhozzáférést. A sandbox elszigeteli a programot a rendszer többi részétől, minimalizálva a károkat egy esetleges kihasználás esetén.

# Futtassunk egy parancsot egy szigorúan korlátozott sandboxban
$ sandbox -X -H /tmp/sandbox-home -t sandbox_t /usr/bin/firefox

Ez a parancs elindítja a Firefoxot egy sandbox környezetben, saját home könyvtárral és szigorúan korlátozott hálózati hozzáféréssel.

A sVirt (Secure Virtualization) az SELinux kiterjesztése a virtualizációs környezetekre (pl. KVM, QEMU). Az sVirt biztosítja, hogy minden virtuális gép (VM) és annak kapcsolódó erőforrásai (lemezképek, hálózati interfészek) egyedi SELinux kontextussal rendelkezzenek. Ez megakadályozza, hogy egy kompromittált VM hozzáférjen más VM-ek adataihoz vagy a gazdagép erőforrásaihoz, ezáltal növelve a virtualizált környezetek biztonságát és elszigetelését.

SELinux a webkiszolgálók és adatbázisok védelmében

A webkiszolgálók (Apache, Nginx) és adatbázisok (MySQL, PostgreSQL) a leggyakoribb célpontjai a támadásoknak. Az SELinux kulcsfontosságú szerepet játszik ezek védelmében:

• Webkiszolgálók: Az SELinux biztosítja, hogy a webkiszolgáló folyamat (pl. httpd_t) csak a statikus webes tartalomhoz (httpd_sys_content_t) férhessen hozzá, és csak a saját naplóiba (httpd_log_t) írhasson. Megakadályozza, hogy a webkiszolgáló hozzáférjen a rendszer konfigurációs fájljaihoz, a felhasználói home könyvtárakhoz (hacsak a httpd_enable_homedirs boolean nincs engedélyezve), vagy kimenő kapcsolatokat kezdeményezzen, ha erre nincs szükség. Ez drámaian csökkenti a támadási felületet.
• Adatbázisok: Hasonlóan, az adatbázis-kezelő rendszerek folyamatai (pl. mysqld_t) csak a saját adatfájljaikhoz (mysqld_db_t) és naplófájljaikhoz (mysqld_log_t) férhetnek hozzá. Az SELinux megakadályozza, hogy az adatbázis-folyamat hozzáférjen a rendszer egyéb fájljaihoz, vagy jogosulatlan hálózati kapcsolatokat létesítsen, még akkor is, ha egy SQL injekció vagy más sérülékenység kompromittálja a szolgáltatást.

SELinux és a harmadik féltől származó alkalmazások

Amikor egy egyedi vagy harmadik féltől származó alkalmazást telepítünk, gyakran szembesülünk SELinux problémákkal, mivel ezek az alkalmazások nem rendelkeznek előre definiált SELinux szabályokkal. Ilyenkor a következő lépéseket érdemes követni:

1. Telepítse az alkalmazást, és próbálja meg elindítani SELinux permissive módban.
2. Figyelje a /var/log/audit/audit.log fájlt az audit2allow vagy sealert segítségével.
3. Azonosítsa a hiányzó jogosultságokat vagy a helytelenül címkézett fájlokat.
4. Ha a fájlok helytelenül vannak címkézve, használja a semanage fcontext parancsot a tartós szabályok hozzáadására, majd futtassa a restorecon-t.
5. Ha a folyamatnak specifikus jogosultságokra van szüksége (pl. hálózati kapcsolat, speciális fájlhozzáférés), és nincs megfelelő boolean, akkor óvatosan hozzon létre egy egyedi SELinux szabályzatmodult az audit2allow segítségével. Fontos, hogy a generált szabályokat a lehető legszűkebbre szabja, és csak a feltétlenül szükséges jogosultságokat adja meg.
6. Miután az alkalmazás stabilan működik permissive módban, kapcsolja vissza az SELinux-ot enforcing módba, és ellenőrizze újra a működést.

Ez a folyamat biztosítja, hogy az egyedi alkalmazások is az SELinux védelme alatt fussanak, anélkül, hogy a rendszer biztonságát gyengítenénk.

SELinux vs. AppArmor: Hasonlóságok és különbségek

Amikor a Linux rendszerek MAC megoldásairól beszélünk, az SELinux mellett gyakran felmerül az AppArmor neve is. Bár mindkét technológia a kötelező hozzáférés-vezérlést valósítja meg, megközelítésükben és működésükben jelentős különbségek vannak.

AppArmor áttekintése

Az AppArmor (Application Armor) egy másik MAC implementáció a Linux kernel számára, amelyet a Novell fejlesztett ki. A Debian, Ubuntu és SUSE Linux disztribúciókban gyakran találkozunk vele alapértelmezett MAC megoldásként.

Az AppArmor a fájlútvonal-alapú hozzáférés-vezérlésre összpontosít. A szabályokat a fájlrendszerbeli elérési útvonalakhoz kötik, és minden alkalmazáshoz egyedi profilokat definiálnak. Ezek a profilok egyszerűbb, könnyebben olvasható formában vannak megírva, mint az SELinux szabályzatok, és általában a /etc/apparmor.d/ könyvtárban tárolódnak.

Az AppArmor profilok két módban működhetnek:

• Enforce mode: A szabályok érvényesítése megtörténik, és minden tiltott művelet blokkolásra kerül.
• Complain mode: A szabályok nem kerülnek érvényesítésre, de a tiltott műveletek naplózásra kerülnek, hasonlóan az SELinux permissive módjához.

Főbb különbségek

Jellemző	SELinux	AppArmor
Alapvető filozófia	Címke-alapú (Labeling-based): Minden objektumhoz és alanyhoz biztonsági kontextust rendel.	Útvonal-alapú (Path-based): Az alkalmazásokhoz tartozó szabályokat fájlrendszerbeli útvonalakhoz köti.
Granularitás	Nagyon finom szemcséjű: Szinte minden kernel objektumra kiterjed (fájlok, folyamatok, hálózat, IPC, képességek).	Közepes szemcséjű: Elsősorban a fájlrendszerhez és a hálózathoz való hozzáférésre fókuszál.
Komplexitás	Magasabb: A szabályzatok összetettebbek, a hibakeresés speciális eszközöket igényel.	Alacsonyabb: A profilok egyszerűbbek, könnyebben érthetők és írhatók.
Szabályzat kezelés	Központi bináris szabályzat, amelyet modulok egészítenek ki. Eszközök: semanage, audit2allow, setsebool.	Alkalmazás-specifikus szöveges profilok. Eszközök: aa-genprof, aa-complain, aa-enforce.
Kernel integráció	Deeply integrated into the Linux Security Module (LSM) framework.	Also uses LSM, but with a different hook set.
Elterjedtség	Red Hat, CentOS, Fedora, AlmaLinux, Rocky Linux, Android.	Debian, Ubuntu, SUSE.
Rugalmasság	Rendkívül rugalmas és kiterjeszthető, szinte bármilyen biztonsági modell megvalósítható.	Könnyebben használható specifikus alkalmazások védelmére, de kevésbé rugalmas az általános rendszerbiztonságban.

Melyiket válasszuk?

A választás jellemzően attól függ, hogy melyik Linux disztribúciót használjuk. Ha Red Hat alapú rendszert (RHEL, CentOS, Fedora stb.) használunk, az SELinux az alapértelmezett és erősen ajánlott megoldás. Ha Debian vagy Ubuntu alapú rendszert használunk, akkor az AppArmor a természetes választás.

Mindkét technológia hatékonyan növeli a rendszer biztonságát a kötelező hozzáférés-vezérlés révén. Az SELinux átfogóbb és finomabb szemcséjű vezérlést biztosít, de meredekebb tanulási görbével jár. Az AppArmor egyszerűbb, és gyorsabban beállítható egyedi alkalmazások védelmére, de kevésbé átfogó a rendszer egészére nézve.

A modern biztonsági megközelítés gyakran kombinálja ezeket a MAC rendszereket más biztonsági eszközökkel (tűzfalak, IDS/IPS, konténer biztonsági megoldások), hogy rétegzett védelmet biztosítson a rendszer számára. Az SELinux, a maga robusztus képességeivel, továbbra is az egyik legfontosabb sarokköve a Linux szerverek biztonságának.

Az SELinux bevált gyakorlatai és jövője

Az SELinux hatékony bevezetése és fenntartása megköveteli a bevált gyakorlatok követését. Bár a kezdeti tanulási görbe meredek lehet, az általa nyújtott biztonsági előnyök felülmúlják a befektetett időt és energiát.

Bevált gyakorlatok

1. Ne tiltsd le! A legfontosabb tanács, hogy ne tiltsuk le az SELinux-ot, még akkor sem, ha problémákba ütközünk. A letiltás jelentősen csökkenti a rendszer biztonságát, és hosszú távon sokkal nagyobb kockázatot jelent, mint az SELinux hibakeresése.
2. Kezdd permissive módban! Új szolgáltatások telepítésekor vagy problémák esetén érdemes az SELinux-ot ideiglenesen permissive módba kapcsolni. Ez lehetővé teszi, hogy az alkalmazások fussanak, miközben az audit naplókba rögzítésre kerülnek a potenciális hozzáférés-megtagadások.
3. Használd a megfelelő eszközöket! Ne próbáld meg kézzel értelmezni a nyers audit naplókat. Használd az sealert-et a gyors elemzéshez, és az audit2allow-t az egyedi szabályok generálásához, de mindig alaposan ellenőrizd a generált szabályokat.
4. Ellenőrizd a fájlkontextusokat! A legtöbb SELinux probléma a helytelen fájlkontextusokból ered. Győződj meg róla, hogy a fájlok és könyvtárak a megfelelő SELinux típussal rendelkeznek, és használd a restorecon-t vagy a semanage fcontext-et a javításra.
5. Keress booleane-eket! Mielőtt egyedi szabályokat írnál, ellenőrizd, hogy van-e már létező boolean, amely engedélyezi a szükséges funkciót. A booleane-ek használata biztonságosabb és egyszerűbb, mint a saját szabályzatmodulok.
6. Tartsd naprakészen a szabályzatot! Győződj meg róla, hogy az SELinux szabályzatod naprakész a disztribúció által biztosított frissítésekkel. Ezek a frissítések gyakran tartalmaznak biztonsági javításokat és új szabályokat a legújabb szoftverekhez.
7. Dokumentáld a változtatásokat! Ha egyedi SELinux szabályokat vagy booleane-eket módosítasz, dokumentáld a változtatásokat és azok indokait. Ez segít a jövőbeli hibakeresésben és a rendszer karbantartásában.

Az SELinux jövője

Az SELinux továbbra is a Linux kernel biztonsági stratégiájának alapvető pillére marad. Fejlődése szorosan kapcsolódik a modern IT trendekhez és kihívásokhoz:

• Konténerizáció és felhő: Ahogy a konténerek és a felhőalapú infrastruktúra egyre elterjedtebbé válik, az SELinux szerepe a workload-ok elszigetelésében és védelmében csak növekedni fog. Az sVirt és a konténer-specifikus SELinux profilok folyamatos fejlesztése biztosítja a biztonságos konténeres környezeteket.
• Serverless és FaaS (Function-as-a-Service): A serverless architektúrákban is szükség van a futtatókörnyezetek szigorú elszigetelésére. Az SELinux, a maga finom szemcséjű vezérlésével, ideális jelölt a funkciók futtatási környezetének korlátozására.
• Mesterséges intelligencia és gépi tanulás: Az AI/ML rendszerek egyre nagyobb mennyiségű érzékeny adatot dolgoznak fel. Az SELinux segíthet biztosítani, hogy ezek a rendszerek csak a számukra engedélyezett adatokhoz férjenek hozzá, és ne szivárogtassanak ki információkat.
• Rendszerintegritás és bizalmasság: Az SELinux alapvető képessége, hogy még a root felhasználókat is korlátozza, továbbra is kulcsfontosságú marad a rendszer integritásának és a bizalmas adatok védelmének biztosításában.

Az SELinux egy rendkívül erőteljes eszköz, amely jelentősen növelheti a Linux rendszerek biztonságát. Bár a kezdeti befektetés a tanulásba és konfigurációba jelentős lehet, a hosszú távú előnyök, különösen a rétegzett védelem és a potenciális támadások elleni ellenállás szempontjából, felbecsülhetetlenek. A folyamatos fejlesztés és a közösség támogatása biztosítja, hogy az SELinux továbbra is az egyik vezető MAC megoldás maradjon a Linux ökoszisztémában.