VirtualBox/VMware futtatása hardened Linux kernelen

Linux

"Ebben a cikkben szemügyre vesszük, hogy hogyan futtathatunk VirtualBox-ot/Vmware-t [olyan] megerősített (hardened) kernelen, amely különböző biztonsági funkciókat tartalmaz az egész rendszer biztonságának fokozása érdekében. [...] Ebben a cikkben a PaX-ot is tartalmazó Grsecurity-t vesszük szemügyre..."

[ Running VirtualBox/VMWare on Hardened Kernel ]

( Huncraft v | 2014. 12. 31., sze – 17:19 )

Ez kb jól össze is foglalja, hogy miért nem biztonságos a mai napig a linux (főként desktopon) - a fontosabb biztonsági intézkedések sajna nem férnek meg sokszor a user igényekkel, mivel a programokat nem ezeket szem előtt tartva írják meg. Jelen esetben is nem egy komolyabb biztonsági funkciót kell deaktiválni, csak hogy ezek a virtualizációs megoldások működjenek (és még így sincs semmi garancia, hogy más program/alkalmazás nem fog fejre állni a grsec integrációja után).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én 2 fő szempontot szoktam figyelembe venni alapjaiban:
- A rendszer biztonsága (főként kernel szintű védelmi mechanizmusok )
- A programok biztonsága (maguk a programok által implementált védelmi mechanizmusok, összhangban a rendszer által elérhetővé tett mechanizmusokkal)

Rendszer szintű védelem tekintetében a BSD-k vannak az élen (OpenBSD részemről) az én meglátásom alapján, bár meg kell jegyezni, hogy Linuxhoz is nagyon sok hardening solution létezik (amik viszont sajna nincsenek merge-elve az alap kernel fába)

Program szintű védelmi megoldások tekintetében megint 2 dolgot kell figyelembe venni:
1.) Azon programok száma és funkcióik, melyek a rendszer biztonsági hiányosságait igyekeznek javítani, avagy a programokat elszeparálni egymástól (Apparmor, SeLinux, Sandboxing megoldások, Chroot)
2.) Alkalmazás szinten implementált biztonsági megoldások (saját sandboxing implementáció, nem szükséges privilégium szint elvetése)

A probléma természetesen mind2 esetben az, hogy a kód minősége (Buffer Overflow, Null pointer, ésatöbbi), illetve a biztonságért felelős rutinok implementálása (crypto, RNG implementáció, logikai hiányosságok) egyik esetben se garantáltan 100%-osak, tehát hiába is vannak meg a biztonsági intézkedések (és ez most a kernelre is érvényes), ha azt át lehet lépni (megfelelő idő és tudás ráfordítással).
Ettől függetlenül, viszont azok megléte igen is növeli a biztonsági szintet (és egyben a rendszer komplexitását is), mivel a támadónak ezek megkerülésére is fel kell készülnie.

Ez alapján az 1. pontban tárgyaltak szempontjából a linux picit talán jobban áll (feltételezve, hogy minden biztonsági mechanizmust implementálsz), viszont ezen biztonsági policy-k folyamatos karbantartása hosszútávon valami gyötrelmes tud lenni.
A 2. pontnál viszont én nem mernék egy rendszert se jobbnak tekinteni, mivel általánosságban elmondható, hogy ha egy rendszer alatt egy biztonsági intézkedést alkalmazás szinten implementálnak, akkor az általában egy másik rendszerben is elérhető lesz annak portolása után. Innentől a kérdés inkább az, hogy a rendszer maga mennyire képes azt magától védeni, illetve, hogy a program az ilyen védelmi mechanizmusokkal mennyire kompatibilis (GrSec esetében sajna sok program pont itt hullik el).

Továbbá persze az is szempont, hogy neked desktop célra milyen programok használata elengedhetetlen :) (sok program ugyan is csak 1-1 OS alatt érhető el)

És akkor itt jön a bibi.. Biztonsági szempontból én OpenBSD-t preferálom (főleg, mert ott 1-1 applikáció kódját át is nézik, illetve ha fontosnak érzik, akkor bele is nyúlnak), viszont Desktop célokra csak erős kompromisszumok mellett használható. Akinek ezen kompromisszumok nem elfogadhatóak, az nagy eséllyel Linuxozni fog, viszont egyek kompromisszumok ott is vissza fognak köszönni, ha az ember tényleg használni is akarja az elérhető hardening megoldásokat (plusz cserébe ott még ezt folyamatosan karban is tarthatja, meg magának forgathatja a kerneleket)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Biztonsági szempontból én OpenBSD-t preferálom (főleg, mert ott 1-1 applikáció kódját át is nézik, illetve ha fontosnak érzik, akkor bele is nyúlnak)

Ez inkább mítosz, mint valóság... Átnézik a kódját annak, ami bekerül a base rendszerbe valamennyire*, a ports fában található applikációkra viszont ez még annyira sem igaz.

valamennyire*: OpenSSL-t is biztos* átnézték anno, amikor először beemelték a base rendszerbe, aztán később ész nélkül frissítették az újabb verziókra, így szépen bepatchelték maguknak a Heartbleed sebezhetőséget és minden más OpenSSL bugot is... Aztán _utólag_ megint megjátszották a nagy fontoskodót és gyorsan forkolták az OpenSSL-t, hogy mutassák ők mennyire törődnek a biztonsággal.

biztos*: Ennek mértéke egyébként is nagy kérdés. Szerintem erősen túl van ez hypeolva és leginkább csak a nyilvánvaló gcc és lint által írt warningokat javítgatják, nincs komoly auditálásról szó (nem rég ráadásul a lint is kikerült a base rendszerből).

A rendszer biztonsága (főként kernel szintű védelmi mechanizmusok )

Kernel önvédelmi mechanizmusokban 10+ éves lemaradásban van az OpenBSD. Egy mai modern Windows is több biztonsági megoldással rendelkezik ezen a téren...

OpenBSD: 99% hype, 1% security

"Kernel önvédelmi mechanizmusokban 10+ éves lemaradásban van az OpenBSD. Egy mai modern Windows is több biztonsági megoldással rendelkezik ezen a téren..."

Ezzel nagyon is tisztában vagyok* :) Viszont a Linuxhoz hasonlítva ahogy látom BSD még mindig előnyben van (legyen az {Free|Open}BSD), bár azt aláírom, hogy Linuxot is lehet úgy hardenelni, hogy biztonságos legyen (talán még biztonságosabb is mint BSD), csupán az baxa a csőröm, hogy onnantól, hogy ezt meglépted folyamatosan neked kell karban tartanod az egész hóbelebancot, kernel kiadásonként manuálisan kernelt patchelni és forgatni, plusz egy csomó kompromisszumot elfogadni (vagy kézzel debugolni 1-1 progot, majd forrást túrni, hogy 1-1 barom fejlesztő hülyeségét az ember helyrepofozhassa).
-> Simán ott lenne a lehetőség arra, hogy jópár megoldást simán bemergeljenek a kernel fába, aztán szépen lassan kiadásonként 1-1 funkciót engedélyezni, hogy aztán az applikáció fejlesztők is kicsit észbe kapjanak, és végre elkezdjenek normális kódot írni, de Linus kézzel-lábbal tiltakozik minden hasonló megmozdulásra.

*Windows-t direkt nem mertem bevenni a kérdésbe, mert nyomban mindenki jött volna a tömérdek példával, hogy Win-t is milyen "könnyen" törnek nap-mint-nap, hogy képzelem, hogy az biztonságos :)

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A Windows egyik legnagyobb gyenge pontja maga a felhasználó. Illetve azért azt se felejtsük el, hogy a blackhat hackerek is inkább azt veszik célba ami legnagyobb számban elterjedt. Ezelőtt a Windows volt a fő célpont. Most az Android hiába, hogy Linux az alap. OS X az BSD alapokra épül mégis több sebezhetőségről tudunk mint az asztali/szerver Linux esetében.

Ha most OS-ek közötti biztonságot nézek, akkor a felhasználó kiesik, tekintve, hogy az ugyan olyan hülye minden rendszer előtt ülve (ugyan úgy rá fog neked nyomni a HACKME gombra Win/Linux/BSD/OSX/etc alatt). Szimplán az van -ahogy te is mondod-, hogy arra mozdulnak rá a legtöbben (abba ölik a legtöbb időt), ami a legprofitálandóbb, ergo mindenki a Win-ben keresik a hibákat orrba-szájba (attól függetlenül, hogy mennyi biztonsági intézkedés van a rendszerbe beleépítve). A legtöbb usernek ebből az jön le, hogy mivel a Win-t támadják a legtöbben, így az a legkevésbé biztonságosabb, ami meg ebben a formában -szerintem- hülyeség -> linuxot is ugyan úgy rommá lehet törni (még könnyebben is), Droidot is, OSXet is ->Nincs teljesen biztonságos rendszer.
Tehát mit tehet a user? Megpróbálhat olyan rendszert használni, amit a kutya se használ (mert arra kisebb eséllyel szop be valami tömegeknek kitalált vírust), esetleg összenézi, hogy melyiknek van jelenleg a legtöbb biztonsági intézkedése a rendszerbe építve, vagy pedig a 2 között próbál lavírozni és utána is jár, hogy melyiknél mekkora biztonsági szintet ér el (ha a Linux részesedése 1% alatti, akkor az ilyen felhasználóé szerintem 0.000001% körül lehet).
Így, vagy úgy, a teljes biztonság csak illúzió lesz (vagy egy teljesen kikapcsolt, bebetonozott, jó mélyre elásott szgép, amit még véletlenül se lehet elindítani)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szerintem nem lehet ilyen szintre leegyszerűsíteni ezt a dolgot. Ez olyan, mintha arra keresnéd a választ, hogy "melyk rendszer a gyorsabb"? Nem lehet megválaszolni anélkül, hogy választanánk egy nézőpontot, egy környezetet, egy kontextust.

Átlag józsi a tömegvírust szopja be, ami ellen elég ha nem használ tömegrendszert. Pl anyám Fedora user (fogalma sincs mi a Fedora), a ~/Download mappája tele gyanús nevű exe, pps, doc, xls fájlokkal pedig nem dolgozik ilyesmivel. Elfogadom, hogy adott szempontból a Windows a legbiztonságosabb, de ha az ő keze alatt lenne, akkor valszeg havonta járhatnék újratelepíteni.
Nézőpont, ugye.

Azért ennél is árnyaltabb a kép: Win alá tény, hogy sokkal több kártevő van, amiből nyomban következik az is, hogy sokan is írnak rá kártevőt, amiből meg az, hogy ezen illetők céljai is eltérőek -> sok hülye már-már egyértelművé teszi, ha megfertőz egy gépet, mások meg próbálnak annyira passzív működést kieszközölni amennyire csak lehetséges. Win esetében nem ritka az előbbi, míg linux esetében inkább az utóbbit tapasztaltam.
Ráadásúl a Wines vírusokat hajlamosak is nagyon hype-olni, Linux vírusokat kevésbé (a legutóbbi -általam ismert- vírus pl. nincs 1 hónapos se).
Szóval hiába van az, hogy a Downloads mappában ott a sok furcsaság, attól még korán sem lehetsz biztos abban, hogy az ott mind az ami a gép ellen indult. Azt meg aztán végképp nehéz garantálni, hogy 1 se volt ami célba sem ért..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Az egyetlen distro amiről tudom, hogy alapból támogatja az Gentoo (annak is a hardened ága), de ahhoz meg hivatalos supportot nem tudsz tudtommal venni (ha van másik amiről tudsz, akkor ne tartsd magadban :)) . Jó, megveheted Spender-től az éves supportot, de ha az egyik musthave programod becrashel 1 funkció engedélyezése után, akkor max ő is annyit mond, hogy "kapcsold ki a funkciót", vagy "értesítd a program készítőjét, és pofoztasd vele helyre az egészet" -> el kéne addig jutni, hogy a programokat is normálisan írják már végre meg, de ahhoz meg az kéne, hogy ezek a funkciók szépen be is szivárogjanak a mainline kernelbe (1x. kikapcsolt, majd pár kiadás után engedélyezett formában). Ezt viszont Linusnak is támogatnia kéne, de a történelem már megmutatta, hogy ez nem nagyon fog bekövetkezni, hiába a folyamatos munkának.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Supportot bármihez tudsz venni, akár Gentoohoz is, csak pénz kérdése... :)

Egyébként nem követem már jó ideje a Linux disztribúciókat, de Gentoo mellett volt néhány anno, amelyik szállított grsec kernelt. Pl. Alpine Linux, vagy a kereskedelmi Atomic Secured Linux. A Debianhoz is készít pl. Corsac grsec kernel csomagokat, de úgy hallottam van mozgolódás a Mempo Linux körül is.

Egyébként Spender meg PaXTeam nem szokott elhajtani senkit, úgyhogy support szerződés nélkül is segíteni szoktak mindenkinek, ha probléma merül fel, de lehet kérdezni az IRC csatornán és a fórumban a többi usertől is. Ha tudok én is szoktam segíteni.

A mainline kernelbe meg kerülnek be egyébként dolgok. Muszáj, hiszen már az Intel is hardveresen valósítgatja meg a PaX védelmi megoldásait, azokat meg támogatniuk kell (lásd XD után most már a kernel exploitok nehezítésére szolgáló SMEP és SMAP funkciók is megtalálhatók az újabb processzorokban, amelyek egy az egyben a PaX UDEREF ötletén alapulnak).

Az Inteles hardveres támogatása miatt egyébként a VirtualBox és a VMware fejlesztőinek muszáj lesz most már javítania azokat a hibákat, amelyeket a PaX UDEREF detektált már eddig is, csak nem foglalkoztak vele.

( Dwokfur v | 2015. 01. 01., cs – 00:12 )

Biztonságos rendszer vs virtuális gép

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."