Windows biztonsági modell illesztőprogram-fejlesztőknek

A Windows biztonsági modell biztonságos objektumokon alapul. Az operációs rendszer minden összetevőjének biztosítania kell azoknak az objektumoknak a biztonságát, amelyekért felelős. Ezért a vezetőknek gondoskodniuk kell az eszközeik és eszközobjektumaik biztonságáról.

Ez a témakör összefoglalja, hogy a Windows biztonsági modell hogyan vonatkozik a kernel módú illesztőprogramokra.

Windows biztonsági modell

A Windows biztonsági modell elsősorban objektumonkénti jogosultságokon alapul, és kevés rendszerszintű jogosultsággal rendelkezik. A védhető objektumok közé tartoznak többek között a folyamatok, a szálak, az események és más szinkronizálási objektumok, valamint a fájlok, könyvtárak és eszközök.

Minden objektumtípus esetében az általános olvasási, írási és végrehajtási jogosultságok részletes objektumspecifikus jogosultságokra képeznek le. Fájlok és könyvtárak esetében például a lehetséges jogosultságok közé tartozik a fájl vagy könyvtár olvasásának vagy írásának joga, a kiterjesztett fájlattribútumok olvasásának vagy írásának joga, a könyvtáron való áthaladás joga, valamint az objektum biztonsági leírójának írásának joga.

A biztonsági modell a következő fogalmakat foglalja magában:

• Biztonsági azonosítók (SID-k)
• Hozzáférési jogkivonatok
• Biztonsági leírók
• Hozzáférés-vezérlési listák (ACL-ek)
• Kiváltságok

Biztonsági azonosítók (SID-k)

A biztonsági azonosító (SID, más néven fő) meghatározza a felhasználót, a csoportot vagy a bejelentkezési munkamenetet. Minden felhasználó egyedi SID-sel rendelkezik, amelyet az operációs rendszer a bejelentkezéskor kér le.

Az SID-ket egy olyan hatóság állítja ki, mint az operációs rendszer vagy egy tartománykiszolgáló. Egyes SID-k jól ismertek, és nevük és azonosítóik is vannak. A SID S-1-1-0 például mindenkit (vagy világot) azonosít.

Hozzáférési jogkivonatok

Minden folyamat rendelkezik hozzáférési jogkivonattal. A hozzáférési jogkivonat a folyamat teljes biztonsági környezetét ismerteti. Tartalmazza a felhasználó SID-címét, azon csoportok SID-azonosítóját, amelyekhez a felhasználó tartozik, valamint a bejelentkezési munkamenet SID-ét, valamint a felhasználó számára biztosított rendszerszintű jogosultságok listáját.

Alapértelmezés szerint a rendszer az elsődleges hozzáférési jogkivonatot használja egy folyamathoz, amikor a folyamat szála egy biztonságos objektummal kommunikál. Egy szál azonban megszemélyesíthet egy ügyfélfiókot. Amikor egy szál megszemélyesít, a saját elsődleges tokenje mellett egy megszemélyesítési tokennel is rendelkezik. A megszemélyesítési jogkivonat annak a felhasználói fióknak a biztonsági környezetét írja le, amelyet a szál megszemélyesít. A megszemélyesítés különösen gyakori a távoli eljáráshívás (RPC) kezelésében.

A szál vagy folyamat korlátozott biztonsági környezetét leíró hozzáférési jogkivonatot korlátozott jogkivonatnak nevezzük. A korlátozott jogkivonatban a SID-k csak a hozzáférés megtagadására állíthatók be, nem a hozzáférés engedélyezésére a biztonságos objektumokhoz. A jogkivonat emellett a rendszerszintű jogosultságok korlátozott halmazát is leírhatja. A felhasználó SID-azonosítója és identitása változatlan marad, de a felhasználó hozzáférési jogosultságai korlátozottak, amíg a folyamat a korlátozott jogkivonatot használja. A CreateRestrictedToken függvény egy korlátozott jogkivonatot hoz létre.

Biztonsági leírók

Minden megnevezett Windows-objektum rendelkezik biztonsági leíróval; néhány névtelen objektum is igen. A biztonsági leíró az objektum tulajdonosi és csoportazonosítóit és ACL-jeit írja le.

Az objektum biztonsági leíróját általában az objektumot létrehozó függvény hozza létre. Amikor egy illesztőprogram meghívja az IoCreateDevice vagy IoCreateDeviceSecure rutint egy eszközobjektum létrehozásához, a rendszer biztonsági leírót alkalmaz a létrehozott eszközobjektumra, és beállítja az objektum ACL-jeit. A legtöbb eszköz esetében az ACL-ek az eszközinformációk (INF) fájlban vannak megadva.

További információkért Biztonsági leírók a kernelillesztő dokumentációjában.

Hozzáférés-vezérlési listák

A hozzáférés-vezérlési listák (ACL-ek) lehetővé teszik az objektumokhoz való hozzáférés részletes szabályozását. Az ACL az egyes objektumok biztonsági leírójának része.

Minden ACL nulla vagy több hozzáférés-vezérlési bejegyzést (ACE) tartalmaz. Minden ACE viszont egyetlen SID-t tartalmaz, amely azonosítja a felhasználót, csoportot vagy számítógépet, valamint az adott SID-hez megtagadott vagy engedélyezett jogosultságok listáját.

Eszközobjektumok ACL-jei

Az eszközobjektum ACL-je háromféleképpen állítható be:

• Állítsa be az eszköztípus alapértelmezett biztonsági leíróját.
• Az RtlCreateSecurityDescriptor függvény programozott módon hozta létre, és az RtlSetDaclSecurityDescriptor függvény állítja be.
• Az eszköz INF-fájljában vagy a IoCreateDeviceSecure rutin hívásában van megadva a Security Descriptor Definition Language (SDDL).

Minden illesztőprogramnak SDDL-t kell használnia az INF-fájlban az eszközobjektumok ACL-jeinek megadásához.

Az SDDL egy bővíthető leírási nyelv, amellyel az összetevők sztringformátumban hozhatnak létre ACL-eket. Az SDDL-t a felhasználói és a kernel módú kód egyaránt használja. Az alábbi ábrán az eszközobjektumok SDDL-sztringjeinek formátuma látható.

Az Access érték határozza meg az engedélyezett hozzáférés típusát. A SID-érték egy biztonsági azonosítót ad meg, amely meghatározza, hogy kire vonatkozik az Access-érték (például egy felhasználó vagy csoport).

A következő SDDL-sztring például mindenhez hozzáférést biztosít a rendszer (SY) számára, és mindenki másnak (WD) csak olvasási hozzáférést biztosít:

“D:P(A;;GA;;;SY)(A;;GR;;;WD)”

A wdmsec.h fejlécfájl olyan előre definiált SDDL-sztringeket is tartalmaz, amelyek alkalmasak az eszközobjektumok számára. A fejlécfájl például így határozza meg az SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX-t:

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"

A sztring első szegmense lehetővé teszi a kernel és az operációs rendszer (SY) teljes vezérlését az eszköz felett. A második szegmens lehetővé teszi, hogy a beépített Rendszergazdák csoport (BA) bárki hozzáférhessen a teljes eszközhöz, de nem módosíthatja az ACL-t. A harmadik szegmens lehetővé teszi, hogy mindenki (WD) olvasson vagy írjon az eszközre, a negyedik szegmens pedig ugyanazokat a jogokat biztosítja a nem megbízható kódhoz (RC). Az illesztőprogramok az előre definiált karakterláncokat változatlanul vagy eszközobjektum-specifikus karakterláncok modelljeként használhatják.

Az összes eszközobjektumnak egy veremben azonos ACL-ekkel kell rendelkeznie. Ha a verem egyik eszközobjektumán módosítja az ACL-eket, az a teljes eszközverem ACL-jeit módosítja.

Ha azonban új eszközobjektumot ad hozzá a veremhez, az nem módosítja az ACL-eket, sem az új eszközobjektumot (ha ACL-ekkel rendelkezik), sem a verem meglévő eszközobjektumait. Amikor egy illesztőprogram létrehoz egy új eszközobjektumot, és a verem tetejére csatolja, az illesztőprogramnak át kell másolnia a verem ACL-jeit az új eszközobjektumba a DeviceObject.Characteristics mező másolásával a következő alsó illesztőből.

Az IoCreateDeviceSecure rutin támogatja az előre definiált SID-ket (például WD-t és SY-t) használó SDDL-sztringek egy részét. A felhasználói módú API-k és az INF-fájlok támogatják a teljes SDDL-szintaxist.

Biztonsági ellenőrzések ACL-ek használatával

Amikor egy folyamat hozzáférést kér egy objektumhoz, a biztonsági ellenőrzések összehasonlítják az objektum ACL-jeit a hívó hozzáférési jogkivonatában található SID-kkel.

A rendszer szigorú felülről lefelé sorrendben hasonlítja össze az ACE-ket, és az első releváns egyezésnél leáll. Ezért az ACL létrehozásakor mindig a megfelelő engedélyezési ACE-k fölé kell helyeznie a megtagadási ACE-eket. Az alábbi példák az összehasonlítás menetét mutatják be.

1. példa: ACL összehasonlítása hozzáférési jogkivonattal

Az 1. példa bemutatja, hogyan hasonlítja össze a rendszer az ACL-t a hívó folyamatának hozzáférési jogkivonatával. Tegyük fel, hogy a hívó meg szeretne nyitni egy fájlt, amely az alábbi táblázatban látható ACL-t tartalmazza.

ACL-mintafájl

Engedély	SID	Hozzáférés
Engedélyez	Könyvelés	Írni, törölni
Engedélyez	Értékesítés	Hozzáfűz
Megtagad	Törvényes	Hozzáfűzés, írás, törlés
Engedélyez	Mindenki	Olvas

Ez az ACL négy ACE-rel rendelkezik, amelyek kifejezetten a Könyvelési, Értékesítési, Jogi és Mindenki csoportra vonatkoznak.

Ezután tegyük fel, hogy a kérési folyamat hozzáférési jogkivonata egy felhasználó és három csoport SID-jét tartalmazza az alábbi sorrendben:

Felhasználó Jim (S-1-5-21...)

Csoport könyvelése (S-1-5-22...)

Jogi csoport (S-1-5-23...)

Mindenki (csoport) (S-1-1-0)

Amikor összehasonlít egy fájl ACL-jét egy hozzáférési jogkivonattal, a rendszer először egy ACE-t keres Jim felhasználó számára a fájl ACL-jében. Semmi sem jelenik meg, így továbbá egy ACE-t keres a könyvelési csoport számára. Ahogy az előző táblázatban is látható, a könyvelési csoport egyik ACE-je jelenik meg a fájl ACL-jének első bejegyzéseként, így Jim folyamata jogosult a fájl írására vagy törlésére, és az összehasonlítás leáll. Ha a Jogi csoport ACE-je ehelyett megelőzi az ACL-ben a Könyvelési csoport ACE-jét, a folyamatnak nem lesz engedélyezve az írási, hozzáfűzési és törlési hozzáférés a fájlhoz.

2. példa: ACL összehasonlítása egy korlátozott hozzáférésű jogkivonattal

A rendszer ugyanúgy hasonlít össze egy ACL-t egy korlátozott jogkivonattal, mint a nem korlátozott jogkivonatokéval. A korlátozott jogkivonatban lévő megtagadási SID azonban csak az ACL-ben lévő megtagadási ACE-nek felel meg.

A 2. példa bemutatja, hogyan hasonlítja össze a rendszer egy fájl ACL-jét egy korlátozott jogkivonattal. Tegyük fel, hogy a fájlban ugyanaz az ACL látható, mint az előző táblázatban. Ebben a példában azonban a folyamat korlátozott jogkivonattal rendelkezik, amely a következő SID-ket tartalmazza:

Felhasználó Jim (S-1-5-21...) Tagad

Csoport könyvelése (S-1-5-22...) Tiltás

Csoport jogi (S-1-5-23...) Tiltás

Mindenki (csoport) (S-1-1-0)

A fájl ACL-je nem sorolja fel Jim SID-jét, ezért a rendszer áttér a könyvelési csoport SID-jére. Bár a fájl ACL-je rendelkezik egy ACE-vel a Könyvelési csoporthoz, ez az ACE lehetővé teszi a hozzáférést; ezért nem egyezik meg a folyamat korlátozott jogkivonatában lévő SID-del, amely megtagadja a hozzáférést. Ennek eredményeképpen a rendszer a jogi csoport SID-jének lép tovább. A fájl ACL-je tartalmaz egy ACE-t a jogi csoporthoz, amely tagadja a hozzáférést, így a folyamat nem tudja írni, hozzáfűzni vagy törölni a fájlt.

Kiváltságok

A jogosultság jog arra, hogy a felhasználó rendszerhez kapcsolódó műveletet hajt végre a helyi számítógépen, például betöltse az illesztőprogramot, módosítsa az időt, vagy állítsa le a rendszert.

A jogosultságok eltérnek a hozzáférési jogosultságoktól, mivel a rendszerhez kapcsolódó feladatokra és erőforrásokra vonatkoznak, és nem az operációs rendszer, hanem a rendszergazda rendeli hozzá őket egy felhasználóhoz vagy csoporthoz.

Az egyes folyamatok hozzáférési jogkivonata tartalmazza a folyamat számára biztosított jogosultságok listáját. Használat előtt kifejezetten engedélyezni kell a jogosultságokat. További információ a jogosultságokról: Jogosultságok a kernelillesztő dokumentációjában.

Biztonsággal kapcsolatos hibakereső parancsok

A !acl bővítmény formázza és megjeleníti a hozzáférés-vezérlési lista (ACL) tartalmát. További információ: Objektum ACL-jének meghatározása és !acl.

A !token bővítmény egy biztonsági jogkivonat-objektum formátált nézetét jeleníti meg. További információ: !token.

A !tokenfields bővítmény megjeleníti a hozzáférési jogkivonat objektumában (a TOKEN struktúrában) lévő mezők nevét és eltolásait. További információ: !tokenfields.

A !sid bővítmény a megadott címen jeleníti meg a biztonsági azonosítót (SID). További információ: !sid.

A !sd bővítmény megjeleníti a biztonsági leírót a megadott címen. További információ: !sd.

Windows biztonsági modell forgatókönyve: Fájl létrehozása

A rendszer a Windows biztonsági modellben leírt biztonsági szerkezeteket használja, amikor egy folyamat leírót hoz létre egy fájlhoz vagy objektumhoz.

Az alábbi ábra azokat a biztonsági műveleteket mutatja be, amelyek akkor aktiválódnak, amikor egy felhasználó módú folyamat megpróbál létrehozni egy fájlt.

Az előző ábra bemutatja, hogyan reagál a rendszer, amikor egy felhasználói módú alkalmazás meghívja a CreateFile függvényt. Az alábbi megjegyzések az ábrán szereplő körkörös számokra vonatkoznak:

1. Egy felhasználói módú alkalmazás meghívja a CreateFile függvényt, és egy érvényes Microsoft Win32-fájlnevet ad át.
2. A felhasználói módú Kernel32.dll átadja a kérést Ntdll.dll, amely a Win32 nevet Microsoft Windows NT-fájlnévvé alakítja.
3. Ntdll.dll windowsos fájlnévvel meghívja az NtCreateFile függvényt. Ntoskrnl.exeesetén az I/O-kezelő kezeli NtCreateFile.
4. Az I/O-kezelő újracsomagolja a kérést egy Object Manager-hívásba.
5. Az Object Manager feloldja a szimbolikus hivatkozásokat, és biztosítja, hogy a felhasználó bejárási jogosultságokkal rendelkezik ahhoz az elérési úthoz, amelyben a fájl létrejön. További információ: Biztonsági ellenőrzések az Object Manager.
6. Az Object Manager meghívja azt a rendszerösszetevőt, amely a kéréshez társított mögöttes objektumtípust birtokolja. Fájllétrehozási kérelem esetén az összetevő az I/O Manager, amely az eszközobjektumok tulajdonosa.
7. Az I/O-kezelő ellenőrzi az eszközobjektum biztonsági leíróját a felhasználói folyamat hozzáférési jogkivonatán, hogy a felhasználó rendelkezzen az eszközhöz szükséges hozzáféréssel. További információkért lásd: Biztonsági ellenőrzések az I/O kezelőben.
8. Ha a felhasználói folyamat rendelkezik a szükséges hozzáféréssel, az I/O-kezelő létrehoz egy leírót, és IRP_MJ_CREATE kérelmet küld az eszköz vagy fájlrendszer illesztőprogramjának.
9. A sofőr szükség szerint további biztonsági ellenőrzéseket végez. Ha például a kérés egy objektumot határoz meg az eszköz névterében, az illesztőprogramnak biztosítania kell, hogy a hívó rendelkezzen a szükséges hozzáférési jogosultságokkal. További információ: Biztonsági ellenőrzések az illesztőprogramban.

Biztonsági ellenőrzések az Object Managerben

A hozzáférési jogosultságok ellenőrzésének felelőssége az ilyen ellenőrzések elvégzésére képes legmagasabb szintű összetevőhöz tartozik. Ha az Objektumkezelő ellenőrizni tudja a hívó hozzáférési jogosultságát, akkor azt megteszi. Ha nem, az Object Manager átadja a kérést az alapul szolgáló objektumtípusért felelős összetevőnek. Ez az összetevő viszont ellenőrzi a hozzáférést, ha lehet; ha nem, a kérést egy még alacsonyabb összetevőnek, például egy illesztőprogramnak továbbítja.

Az Object Manager egyszerű objektumtípusok, például események és mutex-zárolások esetén ellenőrzi az ACL-eket. Névtérrel rendelkező objektumok esetében a típustulajdonos biztonsági ellenőrzéseket végez. Az I/O-kezelőt például az eszközobjektumok és fájlobjektumok típustulajdonosának tekintik. Ha az Objektumkezelő egy eszközobjektum vagy fájlobjektum nevét találja egy név elemzésekor, a nevet átadja az I/O-kezelőnek, ahogyan az a fent bemutatott fájllétrehozási forgatókönyvben is látható. Az I/O-kezelő ezután ellenőrzi a hozzáférési jogosultságokat, ha lehetséges. Ha a név egy objektumot határoz meg egy eszköznévtérben, az I/O-kezelő leküldi a nevet az eszköz (vagy fájlrendszer) illesztőprogramjának, és az illesztőprogram felel a kért hozzáférés ellenőrzéséért.

Biztonsági ellenőrzések az I/O-kezelőben

Amikor az I/O-kezelő létrehoz egy leírót, ellenőrzi az objektum jogosultságait a folyamatelérési jogkivonaton, majd a leíróval együtt tárolja a felhasználó számára biztosított jogokat. A későbbi I/O-kérések érkezésekor az I/O-kezelő ellenőrzi a leíróhoz társított jogosultságokat, hogy a folyamat jogosult legyen a kért I/O-művelet végrehajtására. Ha például a folyamat később írási műveletet kér, az I/O-kezelő ellenőrzi a leíróhoz társított jogosultságokat annak biztosítása érdekében, hogy a hívó írási hozzáféréssel rendelkezzen az objektumhoz.

Ha a fogantyú duplikálva van, a jogosultságok eltávolíthatók a másolatról, de nem adhatók hozzá.

Amikor az I/O Manager létrehoz egy objektumot, az általános Win32-hozzáférési módokat objektumspecifikus jogosultságokká alakítja át. Például a következő jogosultságok vonatkoznak a fájlokra és könyvtárakra:

Win32 hozzáférési mód	Objektumspecifikus jogosultságok
Általános_olvasás	ReadData
GENERIC_WRITE	WriteData
ÁLTALÁNOS_VÉGREHAJTÁS	Attribútumok olvasása
ÁLTALÁNOS_MINDEN	Összes

Fájl létrehozásához a folyamat végrehajtójának bejárási jogosultságokkal kell rendelkeznie a célútvonal szülőkönyvtáraihoz. A \Device\CDROM0\Directory\File.txtlétrehozásához például egy folyamatnak rendelkeznie kell a \Device, \Device\CDROM0 és \Device\CDROM0\Directory átjárási jogával. Az I/O-kezelő csak a könyvtárak bejárási jogosultságát ellenőrzi.

Az I/O-kezelő ellenőrzi a bejárási jogosultságokat a fájlnév elemzésekor. Ha a fájlnév szimbolikus hivatkozás, az I/O-kezelő teljes elérési útra oldja fel, majd a gyökértől kezdve ellenőrzi a bejárási jogosultságokat. Tegyük fel például, hogy a \DosDevices\D szimbolikus hivatkozás a Windows NT eszköznév \Device\CDROM0 nevére mutat. A folyamatnak bejárási jogosultságokkal kell rendelkeznie a \Device könyvtárhoz.

További információ: Object Handles és Object Security.

Biztonsági ellenőrzések az illesztőprogramban

Az operációs rendszer kernele gyakorlatilag minden illesztőprogramot saját névtérrel rendelkező fájlrendszerként kezel. Ezért amikor egy hívó objektumot próbál létrehozni az eszköz névterében, az I/O-kezelő ellenőrzi, hogy a folyamat rendelkezik-e bejárási jogosultságokkal az elérési út címtáraihoz.

WDM-illesztőprogramok esetén az I/O-kezelő nem végez biztonsági ellenőrzéseket a névtéren, kivéve, ha az eszközobjektum FILE_DEVICE_SECURE_OPEN meg van adva. Ha FILE_DEVICE_SECURE_OPEN nincs beállítva, az illesztőprogram felelős a névtér biztonságának biztosításáért. További információ: Eszköznévtér-hozzáférés szabályozása és Eszközobjektumok védelme.

WDF-illesztőprogramok esetén a FILE_DEVICE_SECURE_OPEN jelző mindig be van állítva, így az eszköz biztonsági leírójának ellenőrzése előtt az alkalmazás hozzáférhet az eszköz névterében lévő nevekhez. További információ: Eszközhozzáférés szabályozása a KMDF-illesztőprogramokban.

A Windows biztonsági határai

Az egymással és a különböző jogosultsági szintű felhasználói módú hívókkal kommunikáló illesztőprogramok úgy tekinthetők, hogy átlépik a megbízhatósági határt. A megbízhatósági határ minden olyan kódvégrehajtási útvonal, amely egy alacsonyabb jogosultságú folyamatból egy magasabb jogosultsági szintű folyamatba lép át.

Minél nagyobb az eltérés a jogosultsági szintek között, annál érdekesebb a határ azoknak a támadóknak, amelyek olyan támadásokat szeretnének végrehajtani, mint például a megcélzott illesztőprogram vagy folyamat elleni emelt szintű eszkalációs támadás.

A fenyegetésmodell létrehozásának egyik része a biztonsági határok vizsgálata és a nem várt útvonalak keresése. További információ: nézze meg az Illesztőprogramok fenyegetésmodellezése.

A megbízhatósági határt átlépő adatok nem megbízhatók, ezért ellenőrizni kell őket.

Ez a diagram három kernelillesztőt és két alkalmazást mutat be, egyet egy alkalmazástárolóban és egy rendszergazdai jogosultságokkal futtatott alkalmazást. A piros vonalak a megbízhatósági példák határait jelölik.

Mivel az alkalmazástároló további korlátozásokat tud biztosítani, és nem rendszergazdai szinten fut, az (1) elérési út magasabb kockázati útvonal egy eszkalációs támadáshoz, mivel a megbízhatósági határ egy alkalmazástároló (nagyon alacsony jogosultsági folyamat) és egy kernelillesztő között van.

A (2) elérési út alacsonyabb kockázati útvonal, mivel az alkalmazás rendszergazdai jogosultságokkal fut, és közvetlenül a kernelillesztőbe hív. Az adminisztrátor már eleve elég magas jogosultság a rendszeren, így az adminisztrátorból a kernelre irányuló támadási felület kevésbé vonzó célpont a támadók számára, de még mindig egy figyelmet érdemlő megbízhatósági határvonal.

A (3) elérési út egy példa egy kódvégrehajtási útvonalra, amely több megbízhatósági határt is átlép, amelyeket kihagyhat, ha nem jön létre fenyegetésmodell. Ebben a példában az 1. és a 3. illesztőprogram közötti megbízhatósági határ van, mivel az 1. illesztőprogram a felhasználói módú alkalmazásból veszi a bemenetet, és közvetlenül a 3. illesztőprogramnak továbbítja.

A felhasználói módból az illesztőprogramba érkező összes bemenet nem megbízható, ezért ellenőrizni kell. A más illesztőprogramokból érkező bemenetek szintén megbízhatatlanok lehetnek attól függően, hogy az előző illesztőprogram csak egy egyszerű átengedés volt-e (például az 1. illesztőprogram az 1. alkalmazásból kapott adatokat, az 1. illesztőprogram nem végzett semmilyen ellenőrzést az adatokon, és csak továbbította a 3. illesztőnek). Mindenképpen azonosítsa az összes támadási felületet és megbízhatósági határt, és egy teljes veszélyforrás-modell létrehozásával ellenőrizze az összes adatátlépést.

A Windows biztonsági modellre vonatkozó javaslatok

• Állítson be erős alapértelmezett ACL-eket az IoCreateDeviceSecure rutin hívásaiban.
• Adjon meg ACL-eket az INF-fájlban minden eszközhöz. Ezek az ACL-ek szükség esetén lazíthatják az alapértelmezett ACL-eket.
• Állítsa be a FILE_DEVICE_SECURE_OPEN jellemzőt az eszközobjektum biztonsági beállításainak az eszköznévtérre való alkalmazásához.
• Ne definiáljon olyan IOCTL-eket, amelyek lehetővé teszik FILE_ANY_ACCESS, kivéve, ha az ilyen hozzáférést nem lehet rosszindulatúan kihasználni.
• Az IoValidateDeviceIoControlAccess rutin használatával szigoríthatja a biztonságot a meglévő IOCTLS-eken, amelyek lehetővé teszik a FILE_ANY_ACCESS.
• Hozzon létre egy fenyegetésmodellt, amely megvizsgálja a biztonsági határokat, és nem várt útvonalakat keres. További információ: Illesztőprogramok fenyegetésmodellezése.
• További sofőrbiztonsági javaslatokért tekintse meg a sofőr biztonsági ellenőrzőlistát.

Lásd még:

Eszközobjektumok biztonságossá tétele

Illesztőprogram biztonsági ellenőrzőlistája