Weboldal keresés

Kötelező hozzáférés-vezérlés megvalósítása SELinux vagy AppArmor segítségével Linux alatt

A szabványos ugo/rwx engedélyek és hozzáférési listák által biztosított korlátok leküzdésére és a biztonsági mechanizmusok növelésére az Amerikai Egyesült Államok Nemzetbiztonsági Ügynöksége (NSA) rugalmas < A SELinux (a Security Enhanced Linux rövidítése) a kötelező hozzáférés-szabályozás (MAC) módszer, amely többek között korlátozza a folyamatok azon képességét, a rendszerobjektumokhoz (például fájlok, könyvtárak, hálózati portok stb.) hozzáférhet vagy más műveleteket hajthat végre a lehető legkevesebb engedéllyel, ugyanakkor lehetővé teszi a modell későbbi módosításait.

Egy másik népszerű és széles körben használt MAC az AppArmor, amely a SELinux szolgáltatásai mellett olyan tanulási módot is tartalmaz, amely lehetővé teszi a rendszer számára, hogy „tanuljon ” hogyan viselkedik egy adott alkalmazás, és korlátokat állíthat be profilok konfigurálásával a biztonságos alkalmazáshasználat érdekében.

A CentOS 7 rendszerben a SELinux magába a kernelbe van beépítve, és alapértelmezés szerint Enforcing módban engedélyezve van (erről a következő részben olvashat bővebben), szemben az openSUSE és Ubuntu-val, amelyek az AppArmorot használják.

Ebben a cikkben elmagyarázzuk a SELinux és az AppArmor alapvető tulajdonságait, valamint azt, hogy hogyan használhatja ezeket az eszközöket saját előnyére a választott disztribúciótól függően.

A SELinux bemutatása és használata CentOS 7 rendszeren

A fokozott biztonságú Linux kétféle módon működhet:

  1. Kényszerítés: A SELinux a biztonsági motort vezérlő SELinux házirend-szabályok alapján megtagadja a hozzáférést.
  2. Megengedett: A SELinux nem tagadja meg a hozzáférést, de a megtagadások naplózzák azokat a műveleteket, amelyek megtagadtak volna, ha kényszerítő módban futnának.

A SELinux is letiltható. Bár ez önmagában nem működési mód, mégis egy lehetőség. Az eszköz használatának megtanulása azonban jobb, mint figyelmen kívül hagyni. Tartsd észben!

A SELinux jelenlegi módjának megjelenítéséhez használja a getenforce parancsot. Ha át szeretné váltani a működési módot, használja a setenforce 0 (megengedő) vagy a setenforce 1 (Enforcing) parancsot.).

Mivel ez a módosítás nem éli túl az újraindítást, szerkesztenie kell az /etc/selinux/config fájlt, és a SELINUX változót bármelyikre kell beállítania. enforcing, permissive vagy letiltva az újraindítások közötti állandóság elérése érdekében:

Megjegyzem, ha a getenforce Disabled értékkel tér vissza, akkor módosítania kell az /etc/selinux/config elemet a kívánt üzemmóddal, majd újra kell indítania. Ellenkező esetben nem tudja beállítani (vagy átkapcsolni) a működési módot a setenforce segítségével.

A setenforce egyik tipikus felhasználási módja a SELinux módok közötti váltás (kényszerítésről megengedőre, vagy fordítva) az olyan alkalmazások hibaelhárítása érdekében, amelyek rosszul működik, vagy nem a várt módon működik. Ha a SELinux Megengedett módba állítása után működik, biztos lehet benne, hogy SELinux engedélyekkel kapcsolatos problémát keres.

Két klasszikus eset, amikor valószínűleg meg kell küzdenünk a SELinuxszal:

  1. Az alapértelmezett port módosítása, ahol a démon figyel.
  2. A DocumentRoot direktíva beállítása a /var/www/html könyvtáron kívüli virtuális gazdagéphez.

Nézzük meg ezt a két esetet a következő példák segítségével.

1. PÉLDA: Az sshd démon alapértelmezett portjának módosítása

Az egyik első dolog, amit a rendszergazdák tesznek szervereik biztonsága érdekében, hogy megváltoztatják azt a portot, ahol az SSH-démon figyel, főként a portszkennerek és a külső támadók elrettentésére. Ehhez az /etc/ssh/sshd_config fájlban található Port direktívát használjuk, majd az új portszámot az alábbiak szerint (ebben az esetben a 9999 portot használjuk):


Port 9999

Miután megpróbáltuk újraindítani a szolgáltatást és ellenőriztük az állapotát, látni fogjuk, hogy nem sikerült elindítani:


systemctl restart sshd
systemctl status sshd

Ha megnézzük a /var/log/audit/audit.log fájlt, látni fogjuk, hogy az sshd nem indult el a 9999 porton. a SELinux által, mivel ez egy fenntartott port a JBoss Management szolgáltatás számára (a SELinux naplóüzenetei tartalmazzák az „AVC” szót, hogy könnyen kezelhetők legyenek más üzenetekből azonosítva):


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

Ezen a ponton a legtöbben valószínűleg letiltják a SELinuxot, de mi nem fogjuk. Látni fogjuk, hogy van mód arra, hogy a SELinux és az sshd más porton hallgat, harmóniában éljenek együtt. Győződjön meg arról, hogy telepítve van a policycoreutils-python csomag, és futtassa:


yum install policycoreutils-python

Azon portok listájának megtekintése, amelyeken a SELinux engedélyezi az sshd-t. A következő képen azt is láthatjuk, hogy a 9999 port egy másik szolgáltatás számára volt lefoglalva, így azt egyelőre nem tudjuk más szolgáltatás futtatására használni:


semanage port -l | grep ssh

Természetesen választhatunk másik portot az SSH-hoz, de ha biztosak vagyunk abban, hogy nem kell ezt a gépet használnunk semmilyen JBoss-hoz kapcsolódó szolgáltatáshoz, akkor módosíthatjuk a meglévő SELinux szabályt, és helyette hozzárendelhetjük az SSH-hoz azt a portot:


semanage port -m -t ssh_port_t -p tcp 9999

Ezt követően az első semanage paranccsal ellenőrizhetjük, hogy a port megfelelően van-e hozzárendelve, vagy a -lC opciókkal (a list custom rövidítése):


semanage port -lC
semanage port -l | grep ssh

Most újraindíthatjuk az SSH-t, és a 9999-es porton keresztül csatlakozhatunk a szolgáltatáshoz. Vegye figyelembe, hogy ez a változás túléli az újraindítást.

2. PÉLDA: DocumentRoot kiválasztása a /var/www/html könyvtáron kívül egy virtuális gazdagéphez

Ha be kell állítania egy Apache virtuális gazdagépet a /var/www/html könyvtártól eltérő könyvtár használatával DocumentRootként (például /websrv/sites /gabriel/public_html):


DocumentRoot “/websrv/sites/gabriel/public_html”

Az Apache megtagadja a tartalom kiszolgálását, mert az index.html a default_t SELinux típussal van ellátva, amelyhez az Apache nem fér hozzá:


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

Az előző példához hasonlóan a következő paranccsal ellenőrizheti, hogy ez valóban SELinux-szal kapcsolatos probléma:


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

Ha a /websrv/sites/gabriel/public_html címkéjét rekurzív módon httpd_sys_content_t-ra szeretné módosítani, tegye a következőket:


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

A fenti parancs csak olvasási hozzáférést biztosít az Apache számára a könyvtárhoz és annak tartalmához.

Végül az irányelv alkalmazásához (és a címkemódosítás azonnali érvényesítéséhez) tegye a következőket:


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

Most már el kell érnie a könyvtárat:


wget http://localhost/index.html

A SELinux-szal kapcsolatos további információkért tekintse meg a Fedora 22 SELinux és adminisztrátor útmutatóját.