2018. július 27., péntek

A Windows Vista biztonsági szolgáltatásai - MIC - Mandatory Integrity Control 6. rész

Hogy miért szükséges ez a bűvészkedés a jogosultsági szintekkel? Képzeljük el a következő helyzetet: kapunk egy e-mailt egy csatolmánnyal. Mikor lementjük a fájlt, az rögtön alacsony integritás-szintre kerül, mivel az internetről - egy nem megbízható helyről érkezett. Ezért aztán bármi legyen is a fájl tartalma, mikor lefuttatjuk azt semmi különös nem történhet, mivel - a fentiek alapján - egy alacsony szinten futó folyamat nem férhet hozzá a felhasználó magas, vagy nem jelölt, így közepes szinten lévő adataihoz. Az Internet Explorer védett módja a megbízhatósági szintek köré épült, és mivel a böngésző alapértelmezésként alacson integritás-szinten fut, biztosak lehetünk benne, hogy az Internet Explorer-en kereszül nem települhet többé a rendszerre semmilyen ártó kód. Ezen túlmenően, mivel a Windows munkaasztal közepes szintre van besorolva, a böngészőben esetlegesen lefuttatott ActiveX vezérlő sem küldhet többé olyan megtévesztő üzeneteket a desktopra, miszerint vírustámadás áldozatai lettünk és azonnali hatállyal töltsük le ezt-és-ezt a programot - ami valójában maga a vírus.

2018. július 16., hétfő

A Windows Vista biztonsági szolgáltatásai - MIC - Mandatory Integrity Control 4. rész

A Windows Vista-ban négy integritás-szintet definiáltak a fejlesztők: alacsony, közepes, magas és rendszer. Az egyszerű felhasználók közepes, a (valódi) rendszergazda jogosultságúak pedig magas szinten tevékenykednek. A felhasználó által indított folyamatok vagy az általa létrehozott objektumok öröklik a felhasználó integritás-szintjét, a rendszerszolgáltatások a "rendszer" szintre kapnak belépőt. Ha valamilyen okból kifolyólag egy objektum nem kap integritásszint-jelölést, az operációs rendszer automatikusan közepes szintre sorolja be, ezzel megakadályozva, hogy az alacsony szinten futó folyamatok hozzáférhessenek a nem jelölt objektumokhoz. Az operációs rendszer fájljai alapértelmezésként nem jelöltek, így közepes szinten tartózkodnak, valamint természetesen alkalmazódnak rájuk a megfelelő fájlrendszer-jogosultsági beállítások (ACL) is.

2018. július 5., csütörtök

A Windows Vista biztonsági szolgáltatásai - MIC - Mandatory Integrity Control 3. rész

Amikor a felhasználó egy műveletet végez, a Windows még azelőtt, hogy a fájlrendszerjogosultságokat vizsgálná, összehasonlítja a felhasználó integritás-szintjét a műveletben részt vevő objektumokéval. Ha a felhasználó szintje a domináns - vagyis az objektuméval megegyező vagy magasabb - a Windows engedélyezi a feladat végrehajtását - feltéve, hogy fájlrendszer-szinten is megvan hozzá a kellő engedélye. Ha a felhasználó alacsonyabb szintről próbál manipulálni egy objektumot, a Windows nem engedélyezi a hozzáférést, függetlenül attól, hogy magához a fájlhoz, registry-kulcshoz, vagy egyéb komponenshez különben meglenne a hozzáférése. Láthatjuk tehát, hogy az integritás-szintek minden esetben a fájlrendszer-jogosultságok, vagyis az ACL fölött állnak.

2018. június 24., vasárnap

A Windows Vista biztonsági szolgáltatásai - MIC - Mandatory Integrity Control 2. rész

Amikor bejelentkezünk, a Windows egy adott integritási azonosítót rendel a felhasználónkhoz. Ez az azonosító tartalmazza mindazt az információt, amiből a rendszer megállapítja, hogy mely területekhez van hozzáférésünk és melyekhez nincs. Nem csak a felhasználók, de a védeni kívánt rendszerobjektumok, úgy mint fájlok, mappák, adatcsatornák, folyamatok (processzek), folyamatszálak (thread-ek), az ablakkezelő, registry-kulcsok, szolgáltatások, nyomtatók, megosztások, ütemezett feladatok, stb. is kapnak egy-egy saját szintazonosítót. Ezek az azonosítók a System Access Control List-ben (SACL) tárolódnak, hasonlóan ahhoz, ahogy a fájlrendszerjogosultságok az egyes fájlokhoz tartozó Access Control List-ekben (ACL).

2018. június 13., szerda

A Windows Vista biztonsági szolgáltatásai - MIC - Mandatory Integrity Control 1. rész

A következőkben bemutatásra kerülő védelmi eljárás még egy, az 1970-es években született elgondoláson alapszik, megvalósítására azonban csak napjainkban került sor. Míg a fájlrendszerjogosultságok könnyen kezelhető és hatékony védelmet nyújtanak az illetéktelen hozzáférésektől, a technológia rendelkezik némi korlátoltsággal. Hiába védjük másoktól a fájlokat, ha magát a tulajdonost is viszonylag könnyen rávehetjük, hogy lefuttasson egy-egy parancsot - természetesen adminisztrátori jogokkal. A MIC alapelgondolása a következő: a csökkentett megbízhatósági szinten dolgozó alanyok nem módosíthatnak magasabb szinten lévő objektumokat, a magasabb szinten létező objektumok pedig nem kényszeríthetők, hogy megbízzanak alacsonyabb szintről érkező utasításokban vagy adatokban. A kulcsszó itt a "megbízhatóság", a MIC pedig ezt az információáramlási politikát valósítja meg a Windows Vista-ban.

2018. május 28., hétfő

A Windows Vista biztonsági szolgáltatásai - UAC User Account Control 4.rész UAC fájlrendszer-virtualizáció

Régebben sok problémát okozott egy-egy alkalmazásnál, hogy - tervezési hibából vagy egyéb okokból kifolyólag - csak teljes rendszergazdai jogosultsággal voltak képesek megfelelően futni. Ez a Windows Vista-ban gondot jelenthet, mivel mint minden más alkalmazás, ezek a programok is
csökkentett hatókörrel kell hogy beérjék. A megoldás megint csak a virtuális homokozó. Az olyan programok esetén, melyek a rendszerleíró-adatbázis vagy a fájlrendszer védett helyeire szeretnének írni, az UAC virtualizálja nekik a helyet, vagyis egy könyvtár vagy registry-ág pontos másával
"elhiteti" az alkalmazásokkal, hogy tulajdonképpen a megfelelő helyre írnak, holott természetesen
csak a felhasználó profilkönyvtárában létrehozott mappa- és registry-másolatokban
tevékenykednek. Ezzel a módszerrel megakadályozhatjuk, hogy a régi alkalmazások
teleszemeteljék a rendszermappákat és a registry-adatbázist, valamint elejét vehetjük egy véletlen
(vagy rosszindulatú) módosítás okozta rendszerösszeomlásnak.

2018. május 17., csütörtök

A Windows Vista biztonsági szolgáltatásai - UAC User Account Control 3.rész Internet Explorer Protected Mode

Az UAC nem csak figyelmeztető ablakok feldobálására alkalmas, de neki köszönhetjük, hogy az Internet Explorer 7 képes úgynevezett "védett módban" futni. A védett mód nem más, mint az alkalmazás számára létrehozott virtuális homokozó, ahol kedvére törhet-zúzhat, ha éppen úgy tartja kedve. Ennek a védett módnak akkor vesszük igazán hasznát, ha minden figyelmeztetés, tiltás és riasztás ellenére mégis bejut valahogy egy ártó program az Internet Explorer-en keresztül. Ilyenkor, mivel maga a böngésző is alacsony jogosultsági szinten fut - sot még alacsonyabban, mint a többi (erről később) - a problémás kód nem férhet hozzá szinte semmihez az adott böngészőablakon kívül, ténykedését pedig igen egyszerűen beszűntethetjük, mégpedig az Internet Explorer ablak bezárásával.

2018. május 9., szerda

A Windows Vista biztonsági szolgáltatásai - UAC User Account Control 2.rész

Hogy miért kér a rendszer megerősítést annak ellenére, hogy adminisztrátori jogaink vannak? Mert nincsenek. Hiába áll felhasználónevünk mellett az "administrator" rang, a Windows Vista-ban minden egyes felhasználó korlátozott jogosultsággal ténykedik. Amikor egy művelet végrehajtásához "valódi" rendszergazda jogok szükségesek, az UAC egy úgynevezett szintemelő, vagy eleváló promptot jelenít meg, ahol - beállítástól függően egy gombnyomással vagy jelszó megadásával - egy szinttel feljebb léphetünk, és az adott feladatot (és csak azt!) már rendszergazdaként végezhetjük el. Az UAC azonban sokkal több, mint egy egyszerű megerősítést kérő párbeszédablak. A következő bejegyzésekben bemutatom, milyen egyéb feladata van még a User Account Control-nak.

2018. április 27., péntek

A Windows Vista biztonsági szolgáltatásai - UAC User Account Control 1.rész

Ellentétben az ASLR-rel és a DEP-pel, a User Account Control-tól hangos az internet, amióta csak az első nyilvános Vista bétaváltozatok megjelentek. A legtöbb helyen elsőként említik az új rendszer legidegesítőbb tulajdonságai között, állandó felbukkanó figyelmeztető és kérdő ablakaival, amikkel csak megnehezíti a munkavégzést. Először is szögezzük le, ez ebben a formában nem igaz. A UAC csak programtelepítéskor és adminisztratív feladatok indításakor (pl. rendszerkonfiguráció, vagy hibakeresés) tesz fel kérdéseket, a mindennapi használat közben szinte alig találkozunk vele.

 Az UAC legszembetűnőbb megnyilvánulása a rendszerműveletek végrehajtásakor (akár egy Registry Editor, vagy eseménynapló indításakor) felbukkanó figyelmeztető ablak, mely rákérdez, vajon valóban mi kezdeményeztük-e a programindítást. Ez elsőre talán bután hangzik, egy idő múva pedig akár valóban idegesítővé is válhat. De gondoljunk csak bele, mi történne, ha történetesen mégsem mi, hanem egy rendszerre bejutott vírus kezdene el garázdálkodni a gépen (és természetesen sokkal súlyosabb dologat művelve, mint egy ablak megnyitása). Láthatjuk, hogy a "biztosan Te nyomtad meg a gombot?" típusú kérdések egyáltalán nem is olyan fölöslegesek.

2018. április 16., hétfő

A Windows Vista biztonsági szolgáltatásai - DEP - Data Execution Prevention

Szintén az operatív tár védelmét hivatott ellátni a Data Execution Prevention (más néven NX), azaz az adatvégrehajtás-megtagadás. A technológia működése már nevéből is adódik: megakadályozza, hogy a memóriába olyan területre töltődjön be kód, ahol csak adatok tartózkodhatnának. A korszerű vírusok egyik kedvelt szokása a buffer-túlcsordulásos támadás, ahol is az ártó kód minden esetben adat képében érkezik a kiszemelt alkalmazásba. A DEP úgy védekezik az efajta támadások ellen, hogy az adatszegmensek számára fenntartott memóriacímeket "nem-futtathatóként" jelöli meg, így ezekről a területekről nem indítható kód. A DEP működéséhez operációs rendszer- és processzorszintű támogatás is kell, tehát ez a fajta memóriavédelem csak akkor elérhető, ha a CPU DEPkompatibilis. (A legtöbb ma kapható processzor már rendelkezik ezzel a funkcióval.) A DEP alapértelmezésként csak a beépített Windows szolgáltatásokra engedélyezett, ha minden alkalmazásra ki akarjuk terjeszteni a működését, azt kézzel kell beállítanunk a vezérlőpultban.