Esszé: 12. téma (Windisch Gergely) Linux alkalmazások biztonsága

Linux alkalmazások biztonsága
E tanulmány a három legelterjedtebb linuxos bűvítést ismerteti: AppArmor, GrSecurity és SeLinux.

A probléma
A unix - linux rendszerek eredeti biztonsági filozófiája abból az alapfeltételezésből indult ki, hogy a támadó az mindig valamilyen személy aki más felhasználók vagy a számítógépes rendszer ellen követ- vagy követhet el támadást.

Ebben a világnézetben az operációs rendszer feladata, hogy ha valamely felhasználó rosszindulatú, akkor ellenében védje saját magát és a többi felhasználó erőforrásait.

Ezt a megoldást discretionary access control (DAC) módszernek nevezik és lényege, hogy a felhasználó kap egy erőforrás készletet melyből aztán kedve szerint gazdálkodhat, lehetővé tehet vagy megtilthat hozzáférést más felhasználók számára valamint a felhasználó által futtatott programok ugyanazon jogosultságokkal rendelkeznek mint amivel a felhasználó eredetileg rendelkezett. Ha például rosszindulatú vagy hibásan működő programot telepített, fejlesztett a saját környezetébe, akkor az legfeljebb magának a felhasználónak okozhat kellemetlenséget a saját tulajdonú és elérhetőségű erőforrásokban.

MAC Mandatory Access Control
Ez a DAC megoldással szemben a nagyobb biztonságot nyújtó megoldás

A Wikipédia definíciója, és a hozzáférésvezérlésben elfoglalt helye szerint kizárólagosan rendszergazdai irányítás alatt álló, a többi felhasználó belátására (discretion) nem alapozó, centralizál hozzáférésvezérlési rendszer, és mint ilyen, a Discretionary Access Control (DAC), vagyis a hagyományos (pl. Windows/UNIX), elosztott felelősségvállaláson alapuló fájlrenszerjogosultsági rendszer ellentétpárja.

A technológia és az igények
változásával ez a szemléletmód egyre nehezebben képes megoldást nyújtatni a számítógépes rendszerek biztonságára. Az egyik új keletű probléma, hogy az alkalmazások hatalmas száma és bonyolultsága miatt még egy rendkívül tapasztalt felhasználó sem képes önmaga adatait és gépi erőforrásait teljes mértékben megvédeni. Például ha egy rosszindulatú alkalmazás megszerzi a személy bankszámla adatait az a tradicionális felfogású DAC védelem szemében "nem esemény" hiszen sem a többi felhasználó sem pedig a rendszer adataihoz illetéktelen hozzáférés nem történt, a rendszer működésének feltételeit veszélyeztető esemény tulajdonképpen nem történt így "nincs is probléma", holott még laikus fejjel is belátható, hogy ilyesminek így mégsem kellene megtörténnie.

A másik technológiai változásból fakadó biztonsági probléma az, hogy a mindennapi rendszerhasználat során számos olyan feladatot kell elvégezni amit a tizenöt, húsz évvel ezelőtti unix - linux rendszerekben csak nagyon ritkán és csak kizárólag a rendszergazda volt hivatott cselekedni. Például a ki-be dugdosható adathordozók mountolása-, unmountolása, perifériák csatlakoztatása, webes alkalmazások futtatása. Szervereken a háttérben futó szolgáltatásoknak rendszergazdai jogosultságokat kell biztosítani, hogy elvégezhessenek bizonyos - a működésükhöz nélkülözhetetlen - feladatot. Egy - egy parciális feladat végrehajtásához root jogosultságokat biztosítani olyan, mintha egy vállalati alkalmazott a munkahelyére való bejutás érdekében a teljes irodaépület összes ajtaját nyitni képes szuperkulcsot kapna a kezébe.

Az egész szituációt jól összefoglalja a jobboldali ábra

Ebben a leosztásban például ha az „A” alkalmazást valamilyen külső behatolás során feltörik akkor automatikusan Felhasználó 1. minden személyes adata hozzáférhetővé válik az eltérített „A” alkalmazással. Hasonló probléma áll elő ha a „Z” rendszerszolgáltatás működése valamilyen bug miatt módosítható mert ebben az esetben a „B” alkalmazás feltörésével már nem csupán Felhasználó 2. adatai kerülnek a behatoló kezébe hanem a teljes rendszer minden erőforrása.

A linux kernelről
A kernel központi eleme a Linux operációs rendszereknek.

Ez felelős a rendszer erőforrásaiért, a kommunikációért hardverért és szoftverért, valamint a biztonságért, kritikus szerepet játszik a biztonság magasabb szintű támogatásában.

Alapból sajnos nincs biztonsági funkció beletervezve bár van néhány fontos Linux kernel patch, hogy ezt többé kevésbé képes biztosítani, ezek azonban jelentősen különböznek abban, hogy hogyan kezelik azt és hogyan integrálódnak a rendszerbe.

Restricted user
Rengeteg lehetőség közül az egyik ha a szolgáltatást egy olyan felhasználó futtatja akinek drasztikusan le vannak a jogai korlátozva azon erőforrásokra melyekre feltétlenül szüksége van.

Virtualizáció
Második megoldás ha valamilyen virtuális környezetbe helyezzük az alkalmazást mely egy esetleges betámadás esetén meggátolja a további fontos rendszerelemekhez való hozzáférést. Erre számos szoftver létezik, pl. chroot, virtuális gépek, különféle jail technológiák.

Patchelés
A harmadik lehetőség ha eleve redukáljuk egy alkalmazás eltéríthetőségét pl. olyan módon, hogy behatároljuk a veremkezelést és/vagy adat- kódszegmens funkcióit szeparáljuk annak érdekében, hogy az abnormális - és emiatt gyanús - programviselkedést megakadályozzuk.

Hozzáférés finomabb szabályozása
A negyedik megoldás a MAC technológia beépítése a rendszermagba (kernel). Nyilvánvaló hogy egy-egy alkalmazás vagy rendszerszolgáltatás működéséhez az őt futtató felhasználó teljes jogköre felesleges. Ésszerű megoldásnak tűnik felállítani egy profilt ami megmondja, hogy a védendő alkalmazás jellemzően mit csinál, milyen rendszererőforrásokat használ és ezeket a funkciókat engedélyezni, minden mást tiltani kell. Ehhez linux programozók mindennapos munkaeszköze pl. az strace parancs mely a futtatott programról megmondja, hogy az milyen rendszerhívásokat intéz a kernel felé. Adekvátnak tűnik a megoldás: ha az strace alapján egy olyan keretprogramot hozzunk létre ami folyamatosan figyeli a rendszerhívásokat és ha az nem illeszkedik a konfigurált mintába akkor a műveletet megtagadjuk vagy értesítjük az illetékes adminisztrátort a történtekről.

E tanulmány a három legelterjedtebb linuxos bűvítést ismerteti: AppArmor, GrSecurity és SeLinux.

Történelem
A védelmi funkciók nem egyik napról a másikra alakultak ki hanem a tipikus behatolási módokra apránként születtek work-around megoldások melyek aztán az idő előrehaladtával kanonizálódtak, hivatalos megoldássá léptek elő majd bekerültek az ismertebb linux disztribúciókba is. Az ismertetésre kerülő három bővítés közül a GrSecurity egy kifejezetten ilyen védelmi megoldásokból álló csomag, míg a másik kettő egy-egy önálló szimpla védelmi megoldás. Működéséhez mindhárom megoldás igényel valamilyen linux kernel verziót illetve konkrétan valamilyen célzott kernel támogatást.

GrSecurity
Fejlesztője Brad Spengler

Egy Linux kernel patch halmaz a biztonság hangsúlyozottabb növelésére.

Felderítés, megelőzés, és elszigetelés többrétegű modelljét használja.

GPL licenc.

Funkciók
Intelligens és robusztus Role-Based Access Control (RBAC) rendszer, amely minimális jogosultság politikával működik

/proc tartalmának beszigorítsa

Symlink/hardlink megszorítás

chroot megerősítése

/tmp ütkközések elhárításához FIFO korlátozása

Átfogó ellenőrzés

Önkényes kód végrehajtásának megelőzése, függetlenül az alkalmazott technikától (stack smashing, heap korrupció, stb.)

Önkényes kernelkód végrehajtásának megelőzése

A verem, a könyvtár, és a kupac báziscímeinek véletlnszerű kevergetése amivel a támadó kódot megzavarja

Kernel verem báziscím megkeverése

Kerneles null-pointer dereference hibák bezárása

Érzékeny információk szivárgásának redukálása a kernelszintű önkényesen olvasható memóriatartalom bug betömésével

Felhasználó számára csak a saját folyamatok nézegetésének engedélyezése

Biztonsági riasztásokban és auditokban, az azt kiváltó gép IP-címét rögzíti

Dmesg korlátozása

Csak megbízható elérésű állományok futtatása

GID-alapú foglalat (socket) korlátozás

Közel minden opció sysctl sznten hangolható

Mindenféle riasztás és audit funkció támogatása, mely naplózza a távoli használóIP-címét, a potenciális támadóunix domain socket kapcsolatokon keresztüli elérhetőIP-címét. Védelm a brute-force támadások ellen Low, Medium, High, és opcionális szinten.

Előnyök és hátrányok
Adminisztrációs komplexitás/tanulhatósági görbe - Alacsony

Komplex és hatékony hozzáférés-ellenőrzési mechanizmusok - Nincs (viszont jóval egyszerűbb adminisztrálni, mint a másik két implementációt, emellett szabályokat egyszerűbb létrehozni, mivel nincsenek bonyolult szerep/tartomány/ fájl átmenetek)

Részletes konfiguráció szükséges - Nem (tanulási módban működik)

Kényelmes grafikus konfigurálás - Nincs

Saját konfigurációs nyelv - Igen (gradm)

Egyszerű használat - Igen

Bináris telepítócsomag - elérhető az Ubuntu / RHEL / CentOS / Debian disztribúciókhoz

A rendszer teljesítményére van-e hatás ? - Nincs

Védelmi logika - MAC (pontosabban, annak egy RBAC megvalósítása) hozzáférés-vezérlési listák segítségével

Naplózás támogatott - Igen

Tipikus felhasználói bázis - webszerver és a szolgáltató cégek

Dokumentáció - gyengén dokumentált

Hivatalos projekt oldal: http://grsecurity.net

Elemei

PaX
Fejlesztője a The PaX Team melynek tagjai nem publikusak

2000 októberében jelent meg

A fejlesztése 2005 áprilisa óta szünetel

A legtöbb biztonsági hiba abból ered, hogy a futó programot különféle módszerekkel lehet módosítani. Ezek jelentős része valamilyen puffer túlcsordulásának kezeletlenségéből ered amit valamilyen hibás adatbevitellel el lehet érni. Programhibákon keresztül számos esetben hozzá lehet férni adminisztrátori jogokhoz. Erre pl. régi módszer pl., hogy egy adminisztrátori jogokkal futó hálózati porton klienseket kiszolgáló programot valamilyen ismert hibás inputtal kiakasztunk mire az kilép az őt indító shellprogramba, miközben konzol input/outputja továbbra is a hálózati kapcsolatom marad. Ezzel a módszerrel tulajdonképpen adminisztrátori jogokkal kvázi betelnetezik a támadó és innen bármit megcsinálhat. Ennek a támadási módnak az elkerülésére például a beépített shell helyett egy olyan indító csonkot állítanak a védendő program alá mely konzolon nem kommunikál a felhasználóval ezzel elvágva ezt a támadási lehetőséget. Egy másik ismert támadási módszer például amikor egy alacsonyabb jogosultságokkal rendelkező program manipulálja a visszatérési veremcímet ahova saját eljárásának címét helyezi. Visszatéréskor a processzot a veremben található címre ugrik, de innen már az eredeti hívó program szélesebb jogkörével futtatva azt. A Pax nem véd az olyan tervezési hibáktól amikor maga az alkalmazás tartalmaz súlyos tervezési hibát, pl. ha az valamilyen adatot programként értelmez és az abban foglalt instrukciókat végrehajtja.

Amit konkrétan a Pax elsősorban nyújt az az úgynevezett futási területvédelem mely megakadályozza hogy valamilyen adat szándékolatlanul (illetve behatolási szándékkal) kódként legyen értelmezve, futtatási flag alkalmazásával, címterület-kiosztás összekeverésével, verembázis randomizálással

Szerepkör alapú hozzáférésvezérlés
(Role-based access control)

A linux kernel API több száz függvényt tartalmaz melyek hívását a régebbi verziók nem korlátozták. A felhasználó jogosultságait csupán a fájlrendszeren lehetett érvényesíteni, pl. egy csak a root számára fenntartott programot indíthat vagy nem indíthat. Ez komoly probléma mert a program számára jóval szélesbb jogkör van biztosítba mint ami a feladata elvégzéséhez kell. Az RBAC ennek a szemléletmódnak szerez érvényt. RBAC hozzáférés-vezérlési technológia lehetővé teszi, hogy DAC vagy MAC szabályrendszert kéynszerítsünk az alkalmazásra.

Chroot korlátozása
A linux egyik neuralgikus pontja a chroot nevő eszköz használata. Ez lehetővé teszi hogy egy korlátozandó vagy ismeretlen kevésbé megbízható alkalmazást afféle ketrecbe zárjunk, pl. ha nem szeretnénk teljes adminisztrátori jogot adni neki.

A chroot jail képes elkülöníteni egy bizonyos folyamatot a többi a rendszerkomponenstől, amelyet így fel lehet használni arra, hogy minimalizálja az esetleges károkat ha a szolgáltatás veszélybe kerül. A probléma hogy számos ismert trükk létezik a ketrecből való részleges vagy akár teljes kiszabadulásra, amelyet grsecurity megpróbálj megakadályozni.

Egyéb nem kategorizálható védelmi megoldások
A Linux kernel fokozott ellenőrzése. Be lehet beállítani, hogy ellenőrizzen egy adott felhasználói csoportot, eszközök csatolását/leválasztását, a rendszer idő és dátum változásait. Lehetővé teszi, hogy az admin számára naplózva legyen minden sikertelen erőforrás elérési próbálkozás, pl. futási szál elágazás, IPC létrehozása és/vagy eltávolítása.

A megbízható elérési út engedélyezés egy másik választható lehetőség, arra hogy a felhasználók cak root tulajdonban lévő végrehajtó bináris fájlokat futtathassanak.

Hátrány hogy grsecurity megnehezíti chroot használatát.

Egyéb funkciók, amelyek növelik a felhasználók biztonságát, megakadályozza őket a rendszerről beszerezhető túlzott ismeretektől.

SeLinux
Security-Enhanced Linux (SeLinux). Az USA Nemzetbiztonsági Hivatala által promótált úgynevezett Biztonságos Linux disztribúció volt eredetileg abból a megfontolásból hogy legyen valamilyen kormányzati megoldás ami megfelel a Védelmi Minisztérium hozzáférés szabályozási elveinek.

Funkciói lényegében integrálva lettek a fővonalbeli kernelbe a 2.6-os verziótól. A GrSecurity-hez hasonlóan ez is egy csokor korábbi technológiát és technológia-csomagot szándékozik egyesíteni melyek némi kerneltámogatást is igényelnek.

Ipari területről a projekt fő támogatói a Network Associates, a Secure Computing Corporation, Trusted Computer Solutions, és a Tresys Technology. A jelenlegi disztribúciók közül támogatja a CentOS, RHEL, Fedora Linux, a Debian, Ubuntu, Suse, Slackware és még sok egyéb.

Komponensei
Flux Advanced Security Kernel (FLASK)

Ez már önmagában egy olyan operációs rendszer biztonsági architektúra, amely a hagyományos unixnál rugalmasabb biztonsági politikát támogat, tulajdonképpen egy linux kernel ami a mai biztonsági funkciókat támogatni képes kernelek előfutárának tekinthető. Összesíti azokat a kernelszintű biztonsági megoldásokat melyek már a hetvenes évek elejétől történelmileg felmerültek.

A FLASK főbb részei:

Object Labeling

Az operációs rendszer által kezelt erőforrások egységes azonosítása hogy egyáltalán értelmezni lehessen az ezekhez való hozzáférések jogosultságkezelését.

Client and Server Identification

Ez a mai PKI infrastruktúrában alapvetően nem is igényel magyarázatot. Az ősi rendszerekben ennek igénye még fel sem merült.

Requesting and Caching Security Decisions

Ez felhasználó és csoportkezelés a mai modern értelemben.

Polyinstantiation Support

A hozzáférés-jogosultság eldöntését egy szeparált entitásra bízzuk ennek mikéntjét fedi le a fogalom.

A Linux kernelbe integrált SELinux kikényszeríti a kötelező hozzáférés-ellenőrzési politikát, korlátozhatja a felhasználói programokat munkájuk elvégzéséhez szükséges minimális jogosultsági körre. Ez jelentősen csökkenti vagy megszünteti a lehetőségét hogy a programok és szolgáltatások károsodást okozzanak. Ez az egész mechanizmus a hagyományos Linux-hozzáférési mechanizmusoktól függetlenül működik.

Egy "mezei" linux rendszer (SELinux nélkül) működése függ a kernel helyességétől és minden privilegizált alkalmazástól, konfigurációktól.

Bármely ponton felmerül valami biztonsági probléma, az lehetővé teszi az egész rendszer aláásását.

Ezzel szemben a biztonság egy "átalakított" SE-Linux kernelnél elsősorban a kernel és a biztonsági házirend konfigurációjának helyességétől függ.

Ameddig a szabályok helytállóak, az alkalmazások bizonyos kompromisszumért cserébe nem jelentenek veszélyt az egész rendszerre.

A SELinux felhasználók és szerepek függetlenek a rendszer sajátjaitól. Minden felhasználóhoz és folyamathoz három string attribútumot rendel mely áll a szerepből, felhasználó nevéből, és a tartományból. Ez jóval rugalmasabb a szükségesnél, mezei júzerek osztozhatnak a selinux néven és a hozzáférés szabályaozható a tartományon keresztül. Szabályokon keresztül konfigurálható hogy egy juzer hozzáfér-e egy tartományhoz.

Azt a megoldást ami kapcsolatot teremt a Selinux attribútumai és a valós fájlrendszer között címkézésnek (labelling) nevezzük, ami beépül a fájlrendszerbe és pl. az ls, ps parancsokat -Z opcióval indítva megkapjuk ezek értékét.

Funkciók:
Különválasztva a szabály és annak végrehajtása

Precízen definiált szabályzat interfész

Alkalmazás szintúű támogatás a szabályok lekérdezésére és érvényesítésére

A szabályok függetlenek a specifikálásuk nyelvezetétől

Biztonsági cimkék formátuma független a megvalósítástól

Egyéni cimkék és vezérelvek a kernel saját erőforrásaihoz

Szabályok változtatása támogatott eszközökkel

Különválasztva rendszer integritás és az adatok bizalmassága

Szabályok alkalmazása folamatokra, fájlrendszer elemeire, portokra, hálózati interfészekre

Előnyei és hátrányai
Adminisztráció egyszerűsége (megértés ideje / tanulási görbe) - Nagy

Komplex és hatékony hozzáférés-ellenőrzési mechanizmus - Van

Részletes konfiguráció szükséges - Igen

Grafikus konfigurációs eszközök a szabályok beállítására - Van

Scriptnyelv a szabályrendszer írásához - Van

Egyszerű használat - Nem (néha rémálom)

Bináris csomag - Elérhető a legtöbb Linux disztribúcióhoz

Számottevő hatás a rendszer teljesítményére: Nincs

Biztonsági alaplogika: MAC (Flask implementáció)

Naplózás támogatott - Igen

Tipikus felhasználói bázis - Nagyvállalati felhasználók számára

Dokumentáció - jól dokumentált

Hivatalos project weboldal: http://nsa.gov

AppArmor
Az AppArmort kezdetben az Immunix Linuxban használták (1998-2003), hivatalos disztribúcióban a SUSE és az openSUSE Linuxokban volt elérhető, és a SUSE Linux Enterprise Server 10-ben és az openSUSE 10.1-ben már alapértelmezett volt. 2005-től 2007-ig az AppArmor elsősorban a Novell megoldásának számított és a Novell GPL licensz alatt fut. SubDomain-nek is nevezték utalva legfőbb képességére. Az AppArmor révén biztonsági irányelvek készíthetők a védelmet igénylő Linux-alkalmazásokhoz; ezek kidolgozását a program egy robusztus eszközkészlettel segíti, amely a Linux parancskonzolból vagy a SUSE Linux YaST felületéről érhető el. Az AppArmor úgy próbálja lekezelni a biztonsági problémákat, hogy lekorlátozza az alkalmazások erőforrásokhoz való hozzáférhetőségét és kizárólag csak azokhoz az erőforrásokhoz engedi hozzáférni őket, amelyek feltétlenül szükségesek a megfelelő futásukhoz. Tulajdonképpen a lehető legkisebb privilégiumszintű végrehajtásra szorítja az alkalmazást.

A AppArmor a hivatalos Novell FAQ megfogalmazásában:

Biztonsági keretrendszer, amely proaktívan védi az operációs rendszert és az alkalmazásokat a külső vagy a belső fenyegetésektől akár zero-day támadásoktól is,

szabályai betartatásával még az ismeretlen a szoftverhibák is nehezen válnak kihasználhatóvá.

Az AppArmor az alkalmazások biztonsági profilját teljesen meghatározza így azok csak a számukra megengedett rendszererőforrásokhoz férhetnek hozzá és csak a meghatározott jogosultságokkal.

Az elterjedtebb alkalmazásokhoz előregyártott szabálykészletek állnak rendelkezésre, ezzel egyszerűsítve a konfigurálási munkát, de enélkül is csupán néhány óra még a legösszetettebb alkalmazások konfigurálása is.

Alapértelmezetten szállított csomag az OpenSUSE és a Suse Enterprise Linux disztribúciókban, valamint az Ubuntu Linuxban ezt a megoldást szállították először.

Működése
A biztonsági profilban azoknak a fájloknak a listája található, amelyekhez a program hozzáférhet és azok a műveletek, amelyeket a program végrehajthat. A számítógépes rendszerek tényleges megerősítéséhez minimalizálni kell azon programok számát, amelyek a jogosultságok állítására szolgálnak, majd ezek utána a lehető legjobban meg kell védeni a programokat. Az AppArmor használatakor csak azokhoz a programokhoz kell profilt készíteni, amelyek ki vannak téve a támadás veszélyének. Ez látványosan lecsökkenti a számítógép megerősítéséhez szükséges munka mennyiségét. Az AppArmor profilok irányelvek betartásával garantálja, hogy a programok annyit tehessenek, amennyire jogosultak, de semmivel ne többet. Egy rendszer megerősítése tehát az AppArmor profilhalmaz kidolgozását és karbantartását jelenti, valamint AppArmor jelentéskezelő alrendszere által naplózott irányelvértések és kivételek folyamatos figyelését. Az alkalmazásprofilok frissítésére vagy módosítására csak akkor van szükség, ha a szoftverkonfiguráció vagy a tevékenységek igényelt köre megváltozik. A felhasználók elvileg semmit nem kell, hogy észrevegyenek az AppArmor működéséből. A „színfalak mögött” fut és nem igényel semmilyen felhasználói beavatkozást. Az AppArmor érdemben nem befolyásolja a teljesítményt. Ha az alkalmazás valamely tevékenységét nem fedi le az AppArmor profil, vagy az alkalmazás valamely tevékenységét megakadályozza az AppArmor, akkor a rendszergazdának igazítania kell az alkalmazás profilján, hogy az erre a viselkedésre is kiterjedjen.

Szolgáltatásai
Teljes integráció, könnyű telepítés.

Suse linuxon tartalmaz egy teljes konzolt és YaST-alapú eszkt melyek segítségével a szabályok fejlesztése, telepítése és fenntartása, biztonsági házirendek alkalmazása rendkívül egyszerű.

Védi az operációs rendszert egyedi és külsős féltől származó alkalmazások és külső és belső fenyegetések ellen, a beállított szabályok kikényszerítésével megfelelő alkalmazás viselkedést kéynszerít ki.

Naplózás és riasztás. A beépített funkciók lehetővé teszik, hogy a részletes eseménynaplót, a jelentéseket és riasztásokat a felhasználó által meghatározott eseményekhez Íkonfigurálhassuk.

Sub-process kezelés. Lehetővé teszi, hogy egyéni biztonsági házirendet definiáljunk Perl és a PHP scriptek számára vagy a Web-szerver biztonságának növelésére.

Előnyök és hátrányok
Használat és megtanulás nehézsége - Közepes

Komplex és hatékony hozzáférés-ellenőrzési mechanizmus - Van

Részletes konfiguráció szükséges - Igen

Grafikus eszközök a szabályok írásához/módosításához - Van (yast2 és varázslók)

Saját script nyelv - Van

Egyszerű használat - Igen (gyakran kevésbé összetett és könnyebb az átlagos felhasználó számára, hogy megtanulják, mint a SELinux)

Bináris csomag - elérhető az Ubuntu / SUSE / openSUSE disztribúcióban, stb.

Negatív hatás a rendszer teljesítménye - Nincs

Security Framework - MAC rendszerű

Naplózás - Van

Tipikus felhasználói bázis - Nagyvállalati felhasználók

Dokumentáció - elfogadhatóan dokumentált (többnyire elérhető opensuse és a SuSE Enterprise Linux disztribekhez)

Hivatalos projekt weboldal http://novell.com

Támadásra legesélyesebb programok:
Hálózati ügynökök

A nyitott hálózati portokat kezelő programok (kiszolgálók és kliensek egyaránt). A felhasználói kliensprogramok, például a levelezőkliensek vagy a webböngészők jogosultságait ki lehet használni. Ezek a programok jogosultak írni a felhasználó saját könyvtárát, ugyanakkor potenciálisan veszélyes távoli forrásokból érkező bemeneteket dolgoznak fel (például webhelyek, vagy e-mailben elküldött rosszindulatú kódok).

Webes alkalmazások

A webböngészővel meghívható programok, például CGI Perl parancsfájlok, PHP-oldalak és egyéb, komplex webes alkalmazások.

Cron-nal futtatott feladatok

Olyan programok, amelyeket a cron démon futtat rendszeresen, különféle forrásokból.

Összefoglalás
Mindhárom megoldás elég jó védelmet nyújt, a következő egyszerű szempontok szerint érdemes választani

Új felhasználó / egyszerű használat: grsecurity

Könnyen érthető policy eszközök: AppArmor

A leginkább izmos hozzáférés ellenőrzési mechanizmus: SELinux

Irodalomjegyzék és felhasznált források
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/index.html

http://en.wikipedia.org/.../Security-Enhance...

http://en.wikipedia.org/wiki/AppArmor

http://en.wikipedia.org/wiki/FLASK

http://en.wikipedia.org/wiki/Grsecurity

http://en.wikipedia.org/wiki/Linux

http://en.wikipedia.org/wiki/Linux_kernel

http://en.wikipedia.org/wiki/Linux_Security_Modules

http://en.wikipedia.org/wiki/PaX

http://en.wikipedia.org/wiki/Ptrace

http://en.wikipedia.org/wiki/Role-based_access_control

http://en.wikipedia.org/wiki/Sasser_worm

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

http://en.wikipedia.org/wiki/Selinux

http://en.wikipedia.org/wiki/StackGuard#StackGuard

http://grsecurity.net/

http://hirmagazin.sulinet.hu/hu/30739

http://hirmagazin.sulinet.hu/hu/oktatas/vedelem-nehez-napokra-az-selinux-i

http://neumann.wikia.com/wiki/Oper%C3%A1ci%C3%B3s_rendszerek_%C3%A9s_alkalmaz%C3%A1sok_biztons%C3%A1ga#SeLinux

https://help.ubuntu.com/8.04/.../C/apparmor.html

https://help.ubuntu.com/community/AppArmor

http://lok.hu/egyeb/2007mentes/eloadasok/apparmor_alkalmazasbiztonsag_eloadas03.pdf

http://sugo.ubuntu.hu/10.04/html/.../hu/apparmor.html

https://wiki.ubuntu.com/AppArmor

https://wiki.ubuntu.com/SELinux

http://unixlinux.tmit.bme.hu/AppArmor

http://unixlinux.tmit.bme.hu/Grsecurity

http://wiki.hup.hu/index.php/SELinux

http://www.biztostu.hu/

http://www.crypt.gen.nz/selinux/disable_seli...

http://www.cyberciti.biz/.../selinux-vs-apparmor-vs-grsecu...

http://www.cs.utah.edu/flux/flask/

http://www.kernel.org/doc/htmldocs/kernel-api/index.html

http://www.linuxtopia.org/.../apparmor.../ap...

http://www.linuxvilag.hu/content/files/cikk/61/cikk_61_45_48.pdf

http://www.novell.com/hungary/termekek/linux/apparmor/ -

http://www.nsa.gov/research/selinux/

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-sect1-0015.html

http://www.sulinet.hu/tart/cikk/Rda/0/30739/1http://www.novell.com/hu-hu/documentation/sled10/sled_deployment_sp2/html/SLED-deployment/cha.aaintro.html

http://ubuntuforums.org/showthread.php?t=1008906

Ubuntu Unleashed 2011 Edition Matthew Helmke, with Andrew Hudson, and Paul Hudson Copyright © 2011 by Pearson Education, Inc.

Ubuntu Unleashed 2012 Edition Matthew Helmke, with Andrew Hudson, and Paul Hudson Copyright © 2012 by Pearson Education, Inc.