SELinux és AppArmor útmutató (2026)

Bevezetés: Miért nem elég a hagyományos jogosultságkezelés?

Ha valaha is adminisztráltál Linux szervert éles környezetben, szinte biztos, hogy belefutottál abba a klasszikus rémálomba: egy kompromittált webszerver-folyamat vidáman hozzáfér olyan fájlokhoz, amelyekhez semmi köze. A hagyományos UNIX jogosultságrendszer — a Diszkrecionális Hozzáférés-vezérlés (DAC) — lényegében a fájl tulajdonosára bízza, ki mit csinálhat az adott erőforrással. Ez a modell évtizedeken át egész jól működött, de őszintén? 2026-ban, amikor az AI-vezérelt támadások órákon belül kihasználják az ismert sebezhetőségeket, ez önmagában már kevés.

A megoldás a Kötelező Hozzáférés-vezérlés (Mandatory Access Control — MAC), amit a Linux két meghatározó keretrendszere valósít meg: a SELinux és az AppArmor. Ezek a rendszerek kernel szinten kényszerítenek ki biztonsági szabályokat — még akkor is, ha egy támadó root jogosultságot szerez, a MAC korlátozza, mit tehet valójában.

Egy jól konfigurált MAC-rendszer a legtöbb behatolást egyszerűen zsákutcába tereli. Szóval, nézzük meg mindkét keretrendszert a gyakorlatban.

Ez a cikk a telepítéstől az egyedi szabályzatok írásán át a hibaelhárításig mindent lefed. A cél az, hogy a végére képes legyél saját produkciós környezetedben hatékonyan bevezetni és üzemeltetni bármelyik MAC-megoldást.

A DAC és MAC közötti alapvető különbség

Mielőtt belevetnénk magunkat a technikai részletekbe, gyorsan tisztázzuk a két modell közötti lényegi különbséget — mert ez határozza meg mindent, ami utána jön.

Diszkrecionális Hozzáférés-vezérlés (DAC)

A hagyományos UNIX modellben a fájltulajdonos dönti el, ki olvashatja, írhatja vagy futtathatja a fájlt. Ha egy Apache folyamat www-data felhasználóként fut és a /etc/shadow fájlra van olvasási joga (mondjuk egy misconfiguration miatt), simán el tudja olvasni. A DAC nem tesz különbséget aközött, hogy ki kérte a hozzáférést — csak a jogosultsági bitmaszk számít.

Kötelező Hozzáférés-vezérlés (MAC)

A MAC-rendszerben az operációs rendszer kernele dönt, nem a felhasználó. Minden folyamathoz, fájlhoz és erőforráshoz biztonsági szabályzat tartozik. Még ha egy támadó root jogosultságot is kap, a MAC korlátozza, mely fájlokat érheti el, milyen hálózati portokat nyithat meg, és milyen rendszerhívásokat hajthat végre.

A szabályzatot kizárólag a rendszergazda módosíthatja — a futó folyamatok nem képesek saját engedélyeiket kiterjeszteni.

Gyakorlati szemléltetés

Képzeld el így: a DAC olyan, mint egy irodaház, ahol minden dolgozó maga döntheti el, ki mehet be a szobájába. A MAC ezzel szemben egy központi biztonsági rendszer, ahol az épületfelügyelet határozza meg, ki hova léphet be — és még ha valaki megszerezte is egy dolgozó kulcsát, a központi rendszer akkor is megakadályozza, hogy illetéktelen helyekre jusson.

Egyszerű, ugye? Na, nézzük a gyakorlatot.

SELinux mesterfokon

A Security-Enhanced Linux-ot eredetileg az NSA fejlesztette ki (igen, az az NSA), és ma a Red Hat tartja karban. A RHEL, CentOS, AlmaLinux, Rocky Linux és Fedora rendszerek alapértelmezett MAC-keretrendszere. A SELinux címkealapú (label-based) megközelítést alkalmaz: minden fájlhoz, folyamathoz, porthoz és erőforráshoz biztonsági kontextust rendel, és az ezek közötti interakciókat egy központi szabályzat alapján engedélyezi vagy tiltja.

Telepítés és állapot ellenőrzése

RHEL/CentOS/AlmaLinux rendszereken a SELinux alapértelmezetten telepítve van. Az aktuális állapot ellenőrzéséhez:

# SELinux állapot részletes megjelenítése
sestatus

# Példa kimenet:
# SELinux status:                 enabled
# SELinuxfs mount:                /sys/fs/selinux
# SELinux root directory:         /etc/selinux
# Loaded policy name:             targeted
# Current mode:                   enforcing
# Mode from config file:          enforcing
# Policy MLS status:              enabled
# Policy deny_unknown status:     allowed
# Memory protection checking:     actual (secure)
# Max kernel policy version:      33

Ha a SELinux véletlenül nincs telepítve (ami RHEL-alapú rendszereken elég ritka):

# SELinux telepítése (RHEL/CentOS/AlmaLinux)
sudo dnf install -y selinux-policy selinux-policy-targeted policycoreutils policycoreutils-python-utils setroubleshoot-server

# SELinux engedélyezése a GRUB-ban (ha korábban le volt tiltva)
sudo grubby --update-kernel ALL --remove-args selinux=0

A három üzemmód

A SELinux három üzemmódban működhet, és fontos, hogy tudd, melyik mire való:

Enforcing (Kikényszerítő) — A szabályzat aktívan érvényben van. A tiltott műveletek blokkolásra kerülnek és naplózódnak. Ezt használd production környezetben, mindig.
Permissive (Megengedő) — A szabályzat nem blokkol semmit, de minden szabálysértést naplóz. Teszteléshez és hibaelhárításhoz ideális.
Disabled (Letiltott) — A SELinux teljesen ki van kapcsolva. Soha ne használd production-ben. Komolyan.

# Aktuális üzemmód lekérdezése
getenforce

# Ideiglenes váltás (újraindításig érvényes)
sudo setenforce 0    # Permissive módra váltás
sudo setenforce 1    # Enforcing módra visszaváltás

# Tartós beállítás: /etc/selinux/config szerkesztése
# SELINUX=enforcing

Egy fontos dolog: ha a SELinux-ot disabled-ről enforcing-re kapcsolod, a rendszer újraindítása során a kernel újracímkéz minden fájlt. Nagyobb fájlrendszereken ez akár percekbe is telhet — ne ijedj meg tőle, ez teljesen normális.

Biztonsági kontextusok megértése

A SELinux minden objektumhoz (fájl, folyamat, port) egy biztonsági kontextust rendel. Ez négy részből áll, és megértetni nem is olyan bonyolult, mint elsőre tűnik:

# Fájlkontextusok listázása
ls -Z /var/www/html/
# system_u:object_r:httpd_sys_content_t:s0 index.html

# Folyamatkontextusok listázása
ps -eZ | grep httpd
# system_u:system_r:httpd_t:s0    1234 ?  00:00:05 httpd

# A kontextus formátuma:
# felhasználó:szerep:típus:szint
# system_u  :object_r:httpd_sys_content_t:s0

A típus (type) a legfontosabb elem — a SELinux targeted szabályzatában a hozzáférés-vezérlés döntő többsége a típusok közötti interakciók alapján működik. Például az httpd_t típusú folyamat (Apache) csak httpd_sys_content_t típusú fájlokat olvashat. Logikus, nem?

Boolean-ok: gyors szabályzat-finomhangolás

A SELinux Boolean-ok olyan kapcsolók, amelyekkel a szabályzat egyes aspektusait anélkül módosíthatod, hogy egyedi modult kellene írnod. A valóságban ez a legtöbb probléma leggyorsabb és legegyszerűbb megoldása.

# Összes Boolean listázása
sudo getsebool -a

# HTTP-vel kapcsolatos Boolean-ok szűrése
sudo getsebool -a | grep httpd

# Példa: Apache engedélyezése hálózati kapcsolatok létrehozására
sudo setsebool -P httpd_can_network_connect on

# Példa: Apache engedélyezése a felhasználói home könyvtárak kiszolgálására
sudo setsebool -P httpd_enable_homedirs on

# A -P kapcsoló a beállítást tartóssá teszi (persistent)

Fájlkontextusok kezelése

Na, ez az a téma, ami a legtöbb SELinux-frusztrációt okozza. A leggyakoribb probléma a hibás fájlcímkézés. Ha egy fájlt áthelyezel (mv), megtartja eredeti címkéjét. Ha másolod (cp), az új hely címkéjét örökli. Ez a különbség rengeteg fejfájás forrása — személyes tapasztalatból mondom.

# Fájlkontextus ellenőrzése
ls -Z /var/www/html/app/

# Ha a kontextus hibás, a restorecon helyreállítja az alapértelmezettet
sudo restorecon -Rv /var/www/html/

# Egyedi kontextus tartós hozzárendelése egy könyvtárhoz
sudo semanage fcontext -a -t httpd_sys_content_t "/opt/myapp(/.*)?"
sudo restorecon -Rv /opt/myapp/

# Port kontextus hozzáadása (pl. nem szabványos porton futó szolgáltatás)
sudo semanage port -a -t http_port_t -p tcp 8443
sudo semanage port -l | grep http

Egyedi SELinux-szabályzat írása

Amikor a Boolean-ok és fájlkontextusok nem elegendők, egyedi szabályzatmodult kell írnunk. Ez ritkábban szükséges, de komplex alkalmazásoknál sajnos elkerülhetetlen.

# Fejlesztőeszközök telepítése
sudo dnf install -y selinux-policy-devel

# 1. lépés: A tiltott műveletek azonosítása a naplóból
sudo ausearch -m AVC -ts recent

# 2. lépés: Az audit2allow segítségével kiindulási szabályzat generálása
sudo ausearch -m AVC -ts recent | audit2allow -m myapp_policy

# 3. lépés: A generált .te fájl áttekintése (FONTOS — ne vakon alkalmazd!)
# Példa myapp_policy.te tartalma:
# module myapp_policy 1.0;
#
# require {
#     type myapp_t;
#     type var_log_t;
#     class file { read write open create };
# }
#
# allow myapp_t var_log_t:file { read write open create };

# 4. lépés: Modul fordítása és betöltése
sudo ausearch -m AVC -ts recent | audit2allow -M myapp_policy
sudo semodule -i myapp_policy.pp

# 5. lépés: Ellenőrzés
sudo semodule -l | grep myapp

Kritikus figyelmeztetés: az audit2allow kimenete gyakran túl tág jogosultságokat javasol. Mindig, de tényleg mindig nézd át a generált .te fájlt, és szűkítsd le a jogosultságokat a minimálisan szükségesre. Ha a kimenetben ismeretlen típusokra vonatkozó engedélyeket látsz, az akár egy kompromittálódott rendszer jele is lehet — ilyenkor ne a szabályzatot írd, hanem vizsgáld meg alaposan, mi történt.

SELinux hibaelhárítás lépésről lépésre

Ha valami nem működik SELinux-szal, ne ess pánikba. Kövesd ezt a módszeres hibaelhárítási folyamatot:

# 1. lépés: Ellenőrizd, hogy valóban SELinux okozza-e a problémát
sudo setenforce 0
# Próbáld újra a műveletet. Ha most működik, SELinux-probléma.
sudo setenforce 1

# 2. lépés: Keresd meg a tiltott műveletet az audit naplóban
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent -i

# 3. lépés: Használd a sealert eszközt olvasható elemzéshez
# (a setroubleshoot-server csomag része)
sudo sealert -a /var/log/audit/audit.log | head -50

# A sealert prioritás szerint rendezi a javaslatokat:
# - Legmagasabb megbízhatóság: fájlkontextus-helyreállítás
# - Közepes: Boolean bekapcsolása
# - Legalacsonyabb: egyedi szabályzatmodul

# 4. lépés: A sealert javaslata alapján javíts
# Általában az alábbiak egyike a megoldás:
# a) Fájlkontextus helyreállítása:
sudo restorecon -Rv /problemas/utvonal/
# b) Boolean bekapcsolása:
sudo setsebool -P valamilyen_boolean on
# c) Port címke hozzáadása:
sudo semanage port -a -t szolgaltatas_port_t -p tcp PORT
# d) Egyedi modul (csak végső esetben):
sudo audit2allow -a -M fix_modul && sudo semodule -i fix_modul.pp

AppArmor mesterfokon

Az AppArmor (Application Armor) a Debian, Ubuntu és SUSE alapú disztribúciók alapértelmezett MAC-keretrendszere. A SELinux címkealapú megközelítésével szemben az AppArmor útvonalalapú (path-based) modellt alkalmaz: a biztonsági profilok közvetlenül fájlútvonalak alapján szabályozzák a hozzáférést.

Ez a megközelítés egyszerűbb és jóval intuitívabb, bár néhány szélsőséges esetben kevésbé finom felbontású, mint a SELinux. A legtöbb alkalmazásnál viszont tökéletesen megfelel.

Telepítés és állapot ellenőrzése

Ubuntu rendszereken az AppArmor alapértelmezetten telepítve és engedélyezve van. Az Ubuntu 24.04-es verziótól kezdve az AppArmor közvetlenül a kernelbe van integrálva, szóval nem igazán kell vele bajlódni.

# AppArmor állapot ellenőrzése
sudo aa-status

# Példa kimenet:
# apparmor module is loaded.
# 47 profiles are loaded.
# 47 profiles are in enforce mode.
# 0 profiles are in complain mode.
# 12 processes have profiles defined.
# 12 processes are in enforce mode.

# Szükséges segédeszközök telepítése
sudo apt install -y apparmor-utils apparmor-profiles apparmor-profiles-extra

Profilok és üzemmódok

Az AppArmor profilok egyszerű szöveges fájlok az /etc/apparmor.d/ könyvtárban. Minden profil két módban működhet:

Enforce (Kikényszerítő) — A tiltott műveletek blokkolva és naplózva vannak. Ez kell production-be.
Complain (Panaszkodó) — A tiltott műveletek nem blokkolódnak, de naplózva vannak. Teszteléshez és profilfejlesztéshez tökéletes.

# Profil enforce módba helyezése
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Profil complain módba helyezése
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Profil letiltása (nem ajánlott production-ben)
sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

# Profil újratöltése módosítás után
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

AppArmor profil felépítése

Nézzünk egy egyszerű, de valósághű példát egy Nginx-profilra. Ebből jól látható, hogyan épül fel egy profil a gyakorlatban:

# /etc/apparmor.d/usr.sbin.nginx
#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/openssl>

  # Bináris végrehajtási jog
  /usr/sbin/nginx mr,

  # Konfigurációs fájlok olvasása
  /etc/nginx/** r,
  /etc/ssl/certs/** r,
  /etc/ssl/private/** r,

  # Webtartalom kiszolgálása (csak olvasás)
  /var/www/** r,
  /usr/share/nginx/** r,

  # Naplófájlok írása
  /var/log/nginx/*.log w,
  /var/log/nginx/ r,

  # PID és socket fájlok
  /run/nginx.pid rw,
  /run/nginx/ rw,

  # Hálózati hozzáférés
  network inet stream,
  network inet6 stream,

  # Capability-k (szükséges jogosultságok)
  capability net_bind_service,
  capability setuid,
  capability setgid,
  capability dac_override,

  # Worker folyamatok indítása
  /usr/sbin/nginx ix,

  # Ideiglenes fájlok
  /var/lib/nginx/tmp/** rw,
  owner /tmp/** rw,
}

A jogosultsági betűjelek röviden: r (olvasás), w (írás), m (memórialeképezés végrehajtásként), k (fájlzárolás), l (hard link létrehozás), ix (végrehajtás az aktuális profil öröklésével).

Automatikus profilgenerálás az aa-genprof segítségével

Az AppArmor egyik legnagyobb erőssége az automatikus profilgeneráló eszköz. Megfigyeli egy alkalmazás viselkedését és profilt épít belőle — ez komolyan megkönnyíti az életed:

# 1. lépés: Profilgenerálás indítása
# Ez complain módba helyezi az alkalmazást és figyeli a tevékenységét
sudo aa-genprof /usr/sbin/myapp

# 2. lépés: Egy másik terminálban használd az alkalmazást normálisan
# Végezz el minden tipikus műveletet (fájlolvasás, hálózati kapcsolatok stb.)
sudo systemctl restart myapp
curl http://localhost:8080/
# ...egyéb tipikus műveletek...

# 3. lépés: Térj vissza az aa-genprof terminálhoz
# Nyomj "S"-t a naplóbejegyzések vizsgálatához
# Az eszköz minden észlelt tevékenységre rákérdez:
#   (A)llow - Engedélyezés
#   (D)eny - Tiltás
#   (G)lob - Általánosítás (pl. /var/log/myapp/*.log)
#   A(u)dit - Engedélyezés naplózással

# 4. lépés: Ha végeztél, nyomj "F"-et (Finish)
# A profil enforce módba kerül

# 5. lépés: Finomhangolás a naplók alapján
sudo aa-logprof
# Ez újra végigmegy a naplóbejegyzéseken és javaslatokat tesz

AppArmor hibaelhárítás

Az AppArmor hibakeresése szerencsére egyszerűbb, mint a SELinux-é. Íme a bevált recept:

# 1. lépés: Tiltott műveletek keresése a naplóban
sudo dmesg | grep "apparmor=\"DENIED\""
# vagy
sudo journalctl -k | grep "apparmor=\"DENIED\""

# Példa kimenet:
# audit: type=1400 audit(1711100400.123:456): apparmor="DENIED"
#   operation="open" profile="/usr/sbin/nginx"
#   name="/opt/custom/config.conf" pid=1234 comm="nginx"
#   requested_mask="r" denied_mask="r"

# 2. lépés: A profil complain módba kapcsolása teszteléshez
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# 3. lépés: A problémás művelet végrehajtása

# 4. lépés: A naplóbejegyzések alapján profil frissítése
sudo aa-logprof

# 5. lépés: Visszakapcsolás enforce módba
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

SELinux vs. AppArmor: melyiket válaszd?

Ez a kérdés mindig felmerül, és a válasz nem egyszerűen az, hogy „az egyik jobb, mint a másik". Mindkettőnek megvan a maga erőssége.

Szempont	SELinux	AppArmor
Megközelítés	Címkealapú (label-based)	Útvonalalapú (path-based)
Alapértelmezett disztribúciók	RHEL, CentOS, Fedora, AlmaLinux	Ubuntu, Debian, SUSE
Komplexitás	Magas — meredek tanulási görbe	Alacsony-közepes — könnyebben tanulható
Granularitás	Rendkívül finom — típus, szerep, szint	Közepes — fájlútvonal és capability
MLS/MCS támogatás	Igen — multi-level és multi-category security	Nem
Konténer-izoláció	Kiváló (MCS egyedi címkékkel)	Jó (profil-alapú)
NFS fájlrendszer	Korlátozott (címkézés nem lehetséges)	Teljes támogatás (útvonalalapú)
Hibaelhárítás	sealert, ausearch, audit2allow	aa-logprof, dmesg, journalctl
Ideális felhasználás	Kormányzati, pénzügyi, magas biztonsági környezetek	Webszerverek, alkalmazásszerverek, általános célú szerverek

Gyakorlati tanács: általában azt a keretrendszert érdemes használni, amelyik a disztribúcióddal alapértelmezetten érkezik. RHEL-en ne próbálj AppArmor-t erőltetni, Ubuntu-n pedig ne SELinux-ra váltani — hacsak nincs rá nagyon nyomós okod. Mindkét rendszer megfelelő védelmet nyújt, ha rendesen be van konfigurálva.

Érdekesség egyébként: az openSUSE Tumbleweed és Leap 16 2025-ben áttért az alapértelmezett SELinux-ra. Ez jól mutatja a SELinux növekvő dominanciáját az enterprise szegmensben.

MAC és konténerbiztonság

A konténerizált környezetekben a MAC-keretrendszerek kritikus védelmi réteget jelentenek. A Docker és a Podman egyaránt támogatja mind a SELinux-ot, mind az AppArmor-t — és érdemes is kihasználni őket.

SELinux konténerekkel

# SELinux kontextus ellenőrzése futó konténeren
sudo podman inspect --format "{{.ProcessLabel}}" my_container
# system_u:system_r:container_t:s0:c123,c456

# MCS (Multi-Category Security) biztosítja, hogy
# minden konténer egyedi címkét kap — így nem férhetnek
# hozzá egymás fájlrendszeréhez, még ha azonos node-on is futnak.

# Egyedi SELinux-beállítás konténerhez
sudo podman run --security-opt label=type:my_custom_container_t myimage

# Konténer futtatása SELinux nélkül (NEM AJÁNLOTT production-ben)
sudo podman run --security-opt label=disable myimage

AppArmor konténerekkel

# Docker alapértelmezett AppArmor profil ellenőrzése
sudo docker inspect --format "{{.AppArmorProfile}}" my_container
# docker-default

# Egyedi AppArmor profil alkalmazása konténerre
sudo docker run --security-opt apparmor=my_custom_profile myimage

# AppArmor profil létrehozása Docker konténerhez
# /etc/apparmor.d/docker-custom
#include <tunables/global>

profile docker-custom flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet stream,
  network inet6 stream,

  # Csak a /app könyvtár elérése engedélyezett
  /app/** r,
  /app/data/** rw,

  # Érzékeny területek tiltása
  deny /etc/shadow r,
  deny /etc/passwd w,
  deny /proc/*/mem rw,

  # Capability korlátozás
  capability net_bind_service,
  deny capability sys_admin,
  deny capability sys_ptrace,
}

Bevált gyakorlatok és gyakori hibák

Amit mindig tegyél meg

Mindig Enforcing módban futtasd production-ben — a Permissive/Complain mód kizárólag tesztelésre való.
Fájlokat másold, ne mozgasd — SELinux-nál a cp örökli a célkönyvtár kontextusát, az mv megtartja az eredetit. Ez a különbség sok fejfájást spórolhat meg.
A sealert/aa-logprof javaslatait mindig nézd át — ne vakon alkalmazz automatikus javításokat.
Teszteld staging környezetben — új szabályzatokat és profilokat sosem éles rendszeren próbálj ki először. (Elhidd, megéri az extra időt.)
Verziókezeld a szabályzatokat — a SELinux-modulokat és AppArmor-profilokat kezeld Git-ben, mint bármely infrastruktúra-kódot.
Dokumentáld az egyedi szabályokat — hat hónap múlva nem fogod emlékezni, miért adtad hozzá azt az allow-szabályt. Bízz bennem.

Amit soha ne tegyél

Ne tiltsd le a MAC-ot — ha valami nem működik, derítsd ki az okát. A védelem kikapcsolása nem megoldás, hanem kapitulálás.
Ne használd az audit2allow-t vakon — a generált szabályzat gyakran túl tág, és biztonsági rést nyithat.
Ne hagyd figyelmen kívül a Permissive/Complain naplókat — ezek a naplók pontosan megmutatják, mi történne Enforcing módban.
Ne futtass mindent unconfined_t kontextusban — ez gyakorlatilag kikapcsolt SELinux-szal egyenértékű, és pont az egész MAC lényegét öli meg.

Gyakran ismételt kérdések (GYIK)

Lehet egyszerre SELinux-ot és AppArmor-t is használni ugyanazon a rendszeren?

Technikailag lehetséges, de a gyakorlatban erősen kerülendő. Mindkét keretrendszer Linux Security Module (LSM) implementáció, és együttes futtatásuk konfliktusokhoz, kiszámíthatatlan viselkedéshez és rendkívül nehéz hibaelhárításhoz vezet. Válassz egyet — amelyik a disztribúcióddal jön — és azt konfiguráld alaposan.

Miért blokkol a SELinux egy szolgáltatást, és hogyan derítem ki az okát?

A három leggyakoribb ok: hibás fájlcímkézés (fájl áthelyezés mv-vel), nem szabványos porton futó szolgáltatás (hiányzó port-címke), vagy hiányzó Boolean-beállítás. Első lépésként futtasd a sealert -a /var/log/audit/audit.log parancsot — ez emberi nyelven elmagyarázza a problémát és javaslatot ad a megoldásra.

Mennyire lassítja a SELinux vagy AppArmor a rendszert?

A modern kerneleken a teljesítményveszteség minimális, jellemzően 1-3% között mozog. Normál szerver-terhelésnél ez gyakorlatilag észrevehetetlen. A biztonsági előnyök messze felülmúlják ezt a csekély overhead-et. Ha mégis teljesítményproblémát tapasztalsz, az általában túlságosan komplex vagy rosszul optimalizált szabályzatokra utal — nem magára a MAC-keretrendszerre.

Hogyan védi a MAC a konténereket a breakout-támadásoktól?

A konténerek alapvetően Linux namespace-ekre és cgroup-okra építenek, amelyek izolációt biztosítanak, de nem hermetikus biztonsági határt. A MAC-keretrendszerek (SELinux MCS-sel vagy AppArmor profilokkal) egy plusz réteget adnak hozzá: még ha egy támadó ki is tör a konténer namespace-éből, a MAC-szabályzat korlátozza, mely host-erőforrásokhoz férhet hozzá. Ez drámaian csökkenti a sikeres breakout-támadások hatáskörét.

Érdemes SELinux-ot tanulnom, ha csak Ubuntu-t használok?

Ha kizárólag Ubuntu/Debian környezetben dolgozol, az AppArmor elsajátítása a praktikusabb befektetés. Ugyanakkor ha enterprise környezetben is megfordulsz vagy RHEL/CentOS szervereket is kezelsz, a SELinux ismerete egyszerűen alapvető elvárás. Karrierszempontból mindkettő ismerete komoly előny a munkaerőpiacon — ez egyike azoknak a témáknak, amit érdemes befektetésnek tekinteni.