Mérési útmutató az Access Control (ACC) cím méréshez 2016. április 11. A mérést kidolgozta: Bencsáth Boldizsár Holczer Tamás Papp Dorottya BME, CrySyS Adat- és Rendszerbiztonság Laboratórium
Tartalomjegyzék 1. Bevezetés 3 2. ESXi 3 3. Apache webszerver 4 4. Security Enhanced Linux 5 4.1. Alapfogalmak........................... 5 4.2. Egyéni policy készítése...................... 8 5. Topológia 9 6. Feladatok 9 6.1. ESXi feladatok.......................... 9 6.1.1. Ismerkedés meg az ESXi rendszerrel.......... 10 6.1.2. Er forrás halmazok kezelése............... 10 6.1.3. Felhasználók kezelése................... 10 6.1.4. Szerepek kezelése..................... 10 6.1.5. Telepítés.......................... 11 6.1.6. Automatizált ellen rzés................. 11 6.2. Megosztott webszerver kongurálása két felhasználónak.... 11 6.2.1. Webszerver kongurálása két domain kiszolgálására.. 11 6.2.2. Webszerverre érkez kérések kiszolgálása más-más felhasználók nevében.................... 13 6.2.3. SELinux kongurálása folyamatok jogosultág-kezeléséhez 16 2
1. Bevezetés A mérés célja különböz rendszereken megvalósított hozzáférésvédelmi megoldások vizsgálata. Ennek kapcsán meg lehet ismerkedni az ESXi hozzéférésvédelmi mechanizmusával, a SELinux alapjaival, illetve pár érdekesebb szerver üzemeltetési kérdéssel. 2. ESXi Az ESXi (régebben ESX) a VMWare gyártó virtualizációs megoldása. Az ESXi ellentétben számos más virtualizációs megoldással, nem csupán egy szoftver, ami egy operációs rendszer fölött fut, hanem egy Linuxhoz több szálon köt d kizárólag virtualizációs célokra használt operációs rendszer. A mérés célja, hogy a mér k egy els betekintést kapjanak az ESXi rendszerbe, miközben különböz a jogosultság kezeléssel kapcsolatos feladatokat oldanak meg. Az ESXi jogosultság kezelése a következ fogalmak köre szervez dik: Kezelt objektum (managed object): egy er forrás, amihez valaki hozzá akarhat férni (például virtuális gép, annak egy alkatrésze vagy egy egész ESXi példány) Felhasználó (user): tipikusan jelszóval hitelesített emberi vagy gépi felhasználó. Csoport (group): a felhasználók egy el re deniált halmaza. Privilégium (privilege): egyedi jog, ami szükséges lehet egy m velet elvégzéséhez. Szerep (role): privilégiumok egy el re deniált halmaza. Engedély (permission): egy objektum összekötése egy felhasználóval/csoporttal, hogy az végrehajthasson rajta valamilyen m veletet. Ahogy az látható, a rendszer egy szerep alapú (Role Based Access Control) hozzáférés védelmet valósít meg. Egy adott objektumon egy m veletet csak olyan felhasználók hajthatnak végre, akik rendelkeznek az ehhez szükséges privilégiummal. A könnyebb kezelhet ség miatt a felhasználók csoportokba, míg a privilégiumok szerepekbe rendezhet k. A mérés során a feladatokban a cél olyan felhasználók és szerepek kialakítása, ami biztosítja a kijelölt feladatok elvégzését minimális privilégiumok mellett. A témáról további leírás található az alábbi linkeken: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic= /com.vmware.vsphere.dcadmin.doc_41/vsp_dc_admin_guide/managing_users_ 3
groups_roles_and_permissions/c_managing_users_groups_roles_and_permissions. html https://pubs.vmware.com/vsphere-55/topic/com.vmware.icbase/pdf/ vsphere-esxi-vcenter-server-55-security-guide.pdf 3. Apache webszerver Az Apache2 (https://httpd.apache.org/) egy nyílt forráskódú HTTP szerver UNIX és Windows operációs rendszerek számára. A mérés során a hallgatók egy virtuális Apache2 webszervert kongurálnak be, és betekintést kapnak a megosztott webszerverek üzemeltetésének biztonsági kihívásaiba. Az Apache2 kongurációja ún. direktívák elhelyezésével történik szöveges kongurációs fájlokban. A magasszint konguráció a /etc/apache2/ apache2.conf fájlban található, a hostolt weboldalak kongurációja pedig a /etc/apache2/sites-available mappában. A kongurációs fájlok minden sorában egy direktíva található, melyhez az argumentumokat whitespace karakterekkel elválasztva adhatjuk meg. A # jellel kezd d sorok kommentek. Hogy több weboldalt is üzemeltethessünk ugyanazon a szerveren, virtuális hoszt kongurációkat kell létrehoznunk a VirtualHost direktívával. Argumentumként az IP-címet és portot kell megadnunk, a * minden címre illeszkedik. A VirtualHost direktíván belül többféle kongurációs lehet ségünk van. Az alábbi felsorolás nem teljeskör, csak a mérés elvégzéséhez feltétlen szükséges direktívákat tartalmazza: ServerName: weboldal neve ServerAlias: weboldal alternatív elnevezése DocumentRoot: a mappa, ahol a weboldal fájljai találhatóak ErrorLog: a fájl vagy program, ahova az apache a weboldalhoz tartozó hibákat logolja AccessLog: a fájl vagy program, ahova az apache a beérkez kéréseket logolja A kongurált weboldalakat engedélyezni kell az apache számára. Ezt a a2ensite <konfig fájl> paranccsal tehetjük meg. A parancs kiadása után újra be kell tölteni az apache2 kongurációt (service apache2 reload). A szerver felépítése moduláris: a core csak a legszükségesebb funkciókat tartalmazza, újabb feature-öket modulokon keresztül tölthetünk be. A mérés során az mpm-itk modult fogjuk használni, mely lehet séget nyújt arra, hogy a különböz weboldalakhoz tartozó kéréseket más-más UID és GID alatt szolgáljuk ki. Ehhez a weboldal kongurációjában az AssignUserID <user> <group> direktívát kell felvenni. Ez megosztott webszerver esetén 4
különösen hasznos, mivel a különböz felhasználók weboldalait megvédhetjük egymástól a Unix felhasználói jogosultságkezelésén keresztül. A modul használatának hátulüt je, hogy a modul a háttérben a setuid parancsot használja, vagyis a root nevében kell futtatni. Amennyiben egy támadó képes kitörni a weboldalról, root jogosultságokat szerez a szerveren. Vagyis használatakor további biztonsági mechanizmusokat kell beépíteni a rendszerbe, amivel adott esetben a root nevében futó programok és szolgáltatások jogosultságait is korlátozni tudjuk. 4. Security Enhanced Linux A Security Enhanced Linux (SELinux) egy biztonsági kiegészítés a Linux kernelhez, mely nagyobb felügyeletet biztosít felhasználók és rendszeradminisztrátorok számára egyaránt. A tradícionális hozzáférés védelmet kiegészítve további megkötéseket tehetünk arra vonatkozólag, hogy mely felhasználók és folyamatok mely er forrásokhoz hogyan férhetnek hozzá. A SELinux három m ködési móddal rendelkezik: Enforcing: a SELinux megakadályoz minden tevékenységet, kivéve azokat, amiket valamelyik policy explicit engedélyez; a tevékenységeket naplózza Permissive: a SELinux engedélyezve van és aktívan naplóz, de nem lép közbe, ha tiltania kéne Disabled: a SELinux nincs engedélyezve a gépen, sem logolás, sem tiltás nem történik A aktuális m ködési módot a getenforce vagy sestatus parancsokkal tudjuk megnézni és a setenforce paranccsal vagy a /etc/selinux/config fájlon keresztül tudjuk beállítani. 4.1. Alapfogalmak A hozzáférés-védelem érvényre jutattásához minden fájl, socket, felhasználó, folyamat, stb. rendelkezik egy címkével, amit SELinux kontextusnak nevezünk. A kontextus formátuma user:role:type:level(optional). A fájlok és mappák kontextusait a fájlrendszeren tárolja a számítógép, a folyamatok, portok, stb. kontextusát pedig a kernel menedzseli. A címkék menedzselését (labelingnek) is hívjuk. A kontextusok megtekintéséhez a -Z kapcsolót használhatjuk a különböz listázó programoknál, pl. ls -Z, ps -Z vagy netstat -Z. A kontextus type része egyfajta csoportosítást biztosít a különböz fájlok és objektumok között, folyamat esetében domainnek nevezzük. A type enforcement mehcanizmus felel s annak menedzseléséért, hogy mely kontextussal rendelkez objektumok között megengedett az interakció. Például, 5
az Apache2 webszerver, melyek domainje httpd_t, használhatja a weboldalak fájljait, amelyek típusa httpd_sys_content_t, de nem érheti el a /etc/shadow fájlt, melynek típusa shadow_t. Természetesen el fordulhat, hogy egy folyamatnak más típussal rendelkez objektumhoz kell hozzáférnie. Ezt a kontextusok közötti átmenetet domain transionnek nevezzük és külön engedélyezni kell. A kontextus user része adja meg a SELinux felhasználót, amely nem egyezik meg a hagyományos Linux felhasználókkal. A SELinux felhasználó az a személy, aki a hozzáférés védelmi szabályok szerint bizonyos szerepeket tölthet be. A szabályok minden Linux és SELinux felhasználó között 1:1 megfeleltetést biztosítanak, így a Linux felhasználók megöröklik a SE- Linux felhasználók korlátozásait. A megfeleltetéseket a semanage login -l paranccsal nézhetjük meg. Amennyiben egyik felhasználónak se felel meg a Linux felhasználó, a táblázat default sora jut érvényre. A 1. táblázat egy rövid összefoglalást ad néhány fontosabb SELinux felhasználóról. SELinux user unconned_u root sysadm_u sta_u user_u system_u Leírás Szinte semmilyen korlátozás SELinux felhasználó a root számára SELinux felhasználó rendszergazdai jogosultságokkalb SELinux felhasználó rendszergazdai és végfelhasználói jogosultságokkal egyaránt SELinux felhasználó különleges jogosultságokkal nem rendelkez felhasználók számára Speciális SELinux felhasználó a rendszerfolyamatoknak 1. táblázat. SELinux felhasználók A kontextus role része jelzi a SELinux felhasználó által betöltött szerepet. A SELinux szerepek határozzák meg, hogy milyen domainben lehet a SELinux felhasználó, és ezáltal mely objektumokkal léphet interakcióba. A SELinux felhasználók által felvehet szerepeket a semanage user -l paranccsal nézhetjük meg. A hozzáférés védelemet meghatározó szabályok alkotják policy-t, melynek felépítése moduláris, több bináris fájlban tárolhatóak a szabályok. Funkcionalitása szerint a policy-t az alábbi csoportokba oszthatjuk: Minimum: néhány daemon folyamatot korlátoz, minden más objektum a számítógépen a tradícionális hozzáférés védelem alá tartozik Targeted: számos daemon folyamathoz deniál korlátozásokat, felhasználókat és más objektumokat is képes korlátozni 6
Multi-level security: mérés anyagában többszint hozzáférés-védelem, nem szerepel a Refpolicy: meghatározza, hogy a policy-t buildel folyamatra milyen korlátozások érvényesek A aktuális policy besorolását a /etc/selinux/config fájlban állíthatjuk be. Minden olyan tevékenység, amit a policy szerint meg kell (permissive módban kéne) akadályoznia a SELinuxnak, naplózásra kerül. Ubuntun a következ két fájlt használhatjuk a naplóbejegyzések gy jtésére: /var/log/audit/ audit.log (az auditd csomag szükséges) vagy /var/log/dmesg. A SELinuxhoz kapcsolódó naplóbejegyzések az "AVC" kulcsszóval vannak ellátva, alább láthatunk egy példát. Mivel a naplóbejegyzések formátuma nem közérthet, érdemes ket átadni az audit2why segédprogramnak, ami rövid értelmez szöveget f z a bejegyzésekhez. type=avc msg=audit(1459524851.262:443): avc: denied { read_policy } for pid=1872 comm="audit2allow" scontext=system_u:system_r:sysadm_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security permissive=1 A fenti naplóbejegyzés egy SELinux által dobott hibaüzenetet örökít meg. A bejegyzés szerint a SELinux megakadályozta az audit2allow programnak, ami a system_u:system_r:sysadm_t:s0 kontextusban futott, hogy hozzáférjen egy, a system_u:object_r:security_t:s0 kontextussal rendelkez objektumhoz. A telepített policy-hez mi is adhatunk hozzá újabb szabályokat. Ezt manuálisan, vagy az audit2allow segédprogrammal tehetjük meg. A laboron a segédprogramot fogjuk használni: az /var/log/audit/audit.log fájlból a megfelel SELinux hibaüzeneteket pipe-on keresztül adjuk át a segédprogramnak, ami elkészíti a szabályhalmaz leírását. Alább láthatunk egy példa szabályhalmazt: module sudo-resources-policy 1.0; require { type sysadm_t; type devpts_t; type sysadm_sudo_t; type init_t; type user_tmpfs_t; type tmpfs_t; class fd use; class unix_dgram_socket sendto; class dir search; 7
} class file { read getattr open }; class chr_file { read write getattr ioctl }; #============= sysadm_sudo_t ============== allow sysadm_sudo_t devpts_t:chr_file { read write getattr ioctl }; allow sysadm_sudo_t init_t:fd use; allow sysadm_sudo_t sysadm_t:unix_dgram_socket sendto; allow sysadm_sudo_t tmpfs_t:dir search; allow sysadm_sudo_t user_tmpfs_t:dir search; allow sysadm_sudo_t user_tmpfs_t:file { read getattr open }; A szabályhalmaz három részb l áll. Az els rész a module parancs, ami azonosítja a szabályhalmaz nevét és verzióját. A szabályhalmaz nevének mindig egyedinek kell lennie. A második rész a require blokk, ami leírja, hogy milyen típusoknak, osztályoknak és szerepeknek kell szerepelniük a policy-ben, miel tt ezt a szabályhalmazt telepíthetjük. Az utolsó részben (allow parancsok) vannak felsorolva az engedélyezési szabályok. Léteznek olyan szabályhalmazok a targeted policy-ban, amiknél egyes rendszereken az engedélyezés a logikus, másoknál a tiltás. Ezeket a szabályhalmazokat booleannak nevezzük. Ilyen például a httpd_enable_cgi, ami a CGI szkriptek futtathatóságát szabályozza. Ha webszevert üzemeltetünk és a weboldalon vannak CGI szkriptek, akkor engedélyezni kell ezt a booleant, ha nem webszerver a számítógépünk, vagy nincsenek CGI szkriptek, akkor tiltani. Az elérhet booleanokat a getsebool paranccsal nézhetjük meg, értéküket pedig a setsebool <boolean> <on/off> paranccsal állíthatjuk. 4.2. Egyéni policy készítése Gyakori probléma, hogy a gépen anélkül állítják a SELinuxot enforcing módba, hogy el tte a tipikus felhasználáshoz szükséges policy-ket létrehozták volna. Például, a selinux-policy-default Debian csomagból telepíthet policy nem engedélyezi, hogy a sudo parancs más programot meghívjon. A probléma megoldásához el kell készíteni egy szabályhalmazt, ami ezt a tevékenységet engedélyezi. Ezt megtehetjük manuálisan vagy segédprogram segítségével is, a mérésen az audit2allow segédprogramot fogjuk használni. A segédprogramnak meg kell adnunk azokat a naplóbejegyzéseket, amik a tiltást rögzítik és ebb l elkészíti a policy-t, ami a naplóbejegyzésekben rögzített tevékenységet engedélyezni. A sudo parancs esetében ezt megtehetjük a következ paranccsal: grep AVC /var/log/audit/audit.d grep comm=\"sudo\" audit2allow -M <nev> Kimenetként két fájl keletkezik: <policy_neve>.pp és <nev>.te. Az el bbi a szabályhalmaz bináris leírása, amit semodule -i <nev>.pp paranccsal 8
adhatunk a policy-hez, a másik szövegesen tartalmazza a szabályokat. Megjegyzés: Egyes Linux operációs rendszerek esetében a fejleszt k nem tartják karban a SELinux policy-ket. Ilyen például a Debian és az Ubuntu is. Ha a való életben SELinuxot szeretnénk használni, érdemes egy olyan Linux disztribúciót használni, ahol a letölthet policy-ket a fejleszt csapat aktívan karban tartja (pl. Red Hat, CentOS). A labor során csupán szemléltetésképpen használunk Ubuntut, ahol mindenképp el kell készíteni többféle policy-t a helyes m ködéshez. 5. Topológia Az ESXi-s rész hálózati topológiáját a következ ábra mutatja: A címeket és elérhet ségeket a következ táblázat tartalmazza: Eszköz IP cím Egyéb ESXi A 10.105.0.185 - ESXi B 10.105.0.188 - Deb8 ClientX Dinamikus - Win7 ClientX 10.105.54.4X VNC: 904X ESXi X 10.105.51.X - Ubuntu 14.4 Dinamikus - 6. Feladatok 6.1. ESXi feladatok Ebben a részfeladatban egy mini "cloud"-ot fog létrehozni. A cloudon két független vállalatnak kell helyet biztosítani. Ehhez különböz felhasználókat 9
kell létrehozni, akik üzemeltetni tudják a saját vállalatukhoz tartozó infrastruktúrát. Az infrastruktúra telepítése után, a mérés els harmadának befejezéseként egy scriptet kell létrehozni, ami monitorozza az infrastruktúrát, és szükség esetén beavatkozik. 6.1.1. Ismerkedés meg az ESXi rendszerrel Lépjen be az el re telepített ESXi szerverre a root felhasználóval a Win7-en futó VMWare vsphere Client program segítségével. A felhasználó jelszavát a mérésvezet mondja meg. Ismerkedjen meg a felhasználói felülettel. 6.1.2. Er forrás halmazok kezelése Készítsen két er forrás halmazt (resource pool) két független vállalatnak a grakus felület segítségével. Az er forrás halmazok neve legyen CompanyA és CompanyB. 6.1.3. Felhasználók kezelése Készítsen két adminisztrátort, akik a saját er forrásaikat korlátlanul tudják kezelni. Figyeljen arra, hogy a jogosultságok rekurzív legyen. Figyelje meg, hogy mit lát egy adminisztrátor a másik er forrás halmazból. 6.1.4. Szerepek kezelése Készítsen olyan szerepet, aki csak elindítani, megállítani, és újraindítani tud er forrásokat (Restarter). Készítsen a CompanyA-hoz egy olyan felhasználót (restarter), aki felveszi a Restarter szerepet az er forrás halmazhoz. Készítsen egy olyan felhasználót a CompanyA-hoz, aki ki tudja olvasni a különböz objektumok állapotát, de írni nem tudja ket (tester). Ehhez az el re deniált Read-only szerepet használja. Próbáljon meg belépni és dolgozni a két új felhasználóval. Mit tapasztal? A továbbiakban csak CompanyA-val kell foglalkozni. 6.1.5. Telepítés A következ url-en lév virtuális gép template importálásával készítsen egy virtuális gépet: http://www.crysys.hu/api/education/courses/vihimb01/files/acc_ Ubuntu_template.ova Importálni a File menü Deploy OVF Template parancsával lehet. A mérés második felében ezt a virtuális gépet fogja használni. Az importálásra csak a gyorsabb haladás érdekében van szükség, gyors haladás esetén elkészítheti a saját virtuális gépét is (Ubuntu 14.04 32-bit). 10
6.1.6. Automatizált ellen rzés Készítsen egy olyan scriptet a kiadott váz segítségével, aminek segítségével a telepített virtuális gép futási állapota ellen rizhet. Amennyiben a gép nem megy, akkor a script indítsa el a gépet. A feladat megoldásához az újonnan létrehozott felhasználókat használja, és ne a root usert. http://www.crysys.hu/api/education/courses/vihimb01/files/acc_ vm_checker_restarter.zip A programot a Debianos mér gépr l futtassa. 6.2. Megosztott webszerver kongurálása két felhasználónak 6.2.1. Webszerver kongurálása két domain kiszolgálására A mérés során egy webszerver szolgáltatást nyújtó cég rendszergazdái vagyunk. A cég jelenleg két vev nek nyújtja szolgáltatását: customer-a és customer-b. Rendszergazdaként feladatunk, hogy a két vev nek két weboldalt üzemeltessünk ugyanazon szerveren, melyre a tartalmat a vev k szolgáltatják. Telepítse a virtuális gépre az Apache2-t és a PHP-t! Egy HTTP GET paranccsal ellen rizze, hogy az apache2 elindult és kiszolgálja a kéréseket! Hozzon létre két Linux felhasználót customer-a-nak és customer-b-nek Hozza létre a két vev weboldalainak szánt mappákat a /var/www/ mappában! Hozzon létre a két mappába két próba weboldalt (index.php)! Készítse el és engedélyezze a két weboldal eléréshez szükséges apache2 kongurációs fájlt! A webszerver a vev weboldalával válaszoljon a <vev >.com és a www.<vev >.com kérések esetén is! Kiindulásnak használhatja a /etc/apache2/sites-available/ Megjegyzés: 000-default.conf fájlt. Ellen rizze, hogy elérhet ek-e a weboldalak! Megjegyzés: A /etc/hosts fájlba fel kell venni a szerver IP címe - vev weboldala párosokat, ahonnan a weboldakat böngésszük. 6.2.2. Webszerverre érkez kérések kiszolgálása más-más felhasználók nevében Ezen a ponton ugyan a weboldalak m ködnek, de biztonsági szempontból hiányos a megoldás. Mindkét weboldalt ugyanaz a folyamat (apache2) ugyanazokkal a jogosultságokkal éri el. Ha valamelyik weboldal biztonsági rést 11
tartalmaz, a folyamaton keresztül a másik vev weboldalát is veszélyeztetheti. Ezért szeretnénk, ha az apache2 más-más Linux felhasználó nevében szolgálná ki a vev k weboldalait. Telepítse az apache2-mpm-itk csomagot a szerverre! Megjegyzés: kapjuk: A telepítés során el fordulhat, hogy a következ hibaüzenetet Setting up libapache2-mpm-itk (2.4.6-01-1)... dpkg: error processing package libapache2-mpm-itk (--configure): subprocess installed post-installation script returned error exit status 1 E: Sub-process /usr/bin/dpkg returned an error code (1) Az apache2-mpm-itk az mpm-prefork modult használja, nem pedig az általában engedélyezett mpm-eventet. Az mpm-prefork modult az alábbi parancsokkal engeélyezheti: sudo a2dismod mpm_event sudo a2enmod mpm_prefork sudo service apache2 restart Majd próbálkozzon újra a telepítéssel! Ellen rizze, hogy az apache2 valóban használja-e az mpm-itk modult! A weboldalak kongurációjában állítsa be, hogy a weboldalhoz tartozó Linux felhasználó nevében futtassa a weboldalt az apache2! Indítsa újra az apache2-t! Adja át a felhasználói és csoport jogosultságokat a vev k weboldalát tartalmazó mappán és fájlokon a vev Linux felhasználójának! Távolítsa el rekurzívan az others jogosultságait a vev k weboldalának mappájáról (csak a tulajdonos és a csoport érheti el)! Adjon hozzá az oldalakhoz PHP kódot, ami kiírja, hogy melyik felhasználó nevében kerül feldolgozásra a weboldal! Ellen rizze, hogy a weboldalak továbbra is elérhet ek! 6.2.3. SELinux kongurálása folyamatok jogosultág-kezeléséhez Az apache2-mpm-itk modul a felhasználóváltásokat a setuid segítségével teszi. ezért a root nevében kell futnia. Ezért nem csak a Unix felhasználók jogosultságait kell kezelni a szerveren, hanem a szerveren futó folyamatok jogosultságait is. Erre több lehet ség is létezik Linux rendszerekben, ezen a laboron a SELinux-ot fogjuk megismerni. Megjegyzés: A SELinuxhoz kapcsolódó feladatok megoldása során érdemes egy SSH kapcsolatot fenntartani a géphez, ahol root felhasználók vagyunk. Ha a feladatok során nem tudnánk parancsokat végrehajtani, a root felhasználóval még interakcióban fogunk tudni lépni a SELinux-szal. 12
Telepítse a SELinuxot a webszerverre! Az alábbi csomagokra lesz szükség: selinux-basics, selinux-policy-default, auditd Mivel az Ubuntu nem állítja be a SELinux labeleket a gép indításakor, készítettek egy scriptet, ami ezeket a beállításokat megcsinálja. A script a http://www.crysys.hu/api/education/courses/vihimb01/files/_load_ selinux_policy weboldalon érhet el Másolja fel a szerverre a linken elérhet _load_selinux_policy fájlt! Adja ki az alábbi parancsokat, hogy a policy betölt djön a rendszer indulásakor! sudo mv _load_selinux_policy /usr/share/initramfs-tools/scripts/init-bottom/_load_selinux_policy sudo update-initramfs -u Aktiválja a SELinuxot és indítsa újra a szervert! Megjegyzés: Aktiválni a selinux-activate paranccsal lehet. Újraindulás közben a SELinux beállítja a fájlrendszeren a kontextusokat, ez eltarthat néhány percig. Milyen módban fut a SELinux a gépen? Milyen labelt kaptak az apache2 által kezelt weboldalak? Milyen boolean értékek kapcsolódnak az apache2-höz? Miután meggy z dött arról, hogy van egy root kapcsolata a szerverhez, változtassa meg a SELinux m ködési módját "enforcing"-ra! Váljon root-tá! Mit tapasztal? Miért? Megjegyzés: A felhasználóhoz tartozó SELinux labelt az id -Z paranccsal nézhetjük meg. Javítsa a hibát a root ablakból: vegyen fel megfeleltetést a Linux rendszergazda felhasználó (meres) és a sysadm_u SELinux felhasználó között állítsa a SELinuxot permissive módba indítsa újra a rendszergazda felhasználó sessionjét (kijelentkezés, ha a vsphere clienten keresztül használják a gépet, putty-ban reload session vagy ezekkel ekvivalens megoldás) (bejelentkezés után ellen rizze, hogy a SELinux a felhasználót sysadm_uként jelöli meg a kontextusban) adja ki a sudo su parancsot (fontos, hogy jelszóellen rzés is történjen!) 13
válassza ki a /var/log/audit/audit.log fájlból a sudo su parancs által generált hibaüzeneteket a hibaüzenetek felhasználásával készítsen policy-t, ami engedélyezi a parancs lefutását töltse be a policy-t a SELinuxba állítsa a SELinuxot enforcing módba ellen rizze, hogy a parancs lefut 14