1 Védelem és biztonság (Security) Célok és feladatok Kockázatok és védelem Alapfogalmak Védelmi tartományok Hozzáférési jogok, listák, mátrixok A védelmi politika SETUID
2 Védelem: célok és feladatok A rendszermenedzsment legfontosabb feladatai: A rendszer installálása, hangolása (setting up), méretre alakítása, karbantartása (updating), erőforrás kezelés, kontrol: újabb eszközök, perifériák felvétele, levétele (connecting devices). A rendszer indítása, leállítása (startup-shutdown). Konfigurációs fájlok karbantartása, adott időben futtatandó parancsok indítása, kommunikációs beállítások, stb. A felhasználók menedzselése (felvétel, törlés, jogosultságok kiosztása stb.). A fájlrendszer mentése, visszaállítása (backup, restore, recovery). A fájlrendszer integritás biztosítása, szabad terület (free space) karbantartás. Naplózások, események figyelése (monitoring), statisztikák készítése, számlázás. Szinte mindegyik tevékenység kapcsolatos a biztonsággal. Nagy rendszereknél a rendszermenedzser mellett külön biztonsági menedzsert (security manager) foglalkoztatnak.
3 A védelem célja: biztosítani, hogy minden objektum (szoftver és hardver) korrekt módon működjön, legyen elérhető/kezelhető, és kizárólag azon processzusok által, amelyeknek az elérés megengedett. A feladatai: a rendszermenedzsmenti feladatok korrekt végrehajtásának támogatása és biztosítása.
4 Kockázatok és védelem Általános szabály: a biztonságossá tételnek ára van. Ezért figyelembe kell venni a gép (rendszer) fontosságát, a biztonsági munkák mennyiségét, a biztonsági komponensek hatását a felhasználókra. Olyan egyensúlyt kell keresni, hogy a biztonsági komponensek/műveletek ne legyenek bosszantóak, hátráltatóak.
5 A fenyegetések osztályai I. Fizikai fenyegetések Természeti csapások (tűz, földrengés, árvíz, stb.) Jogosulatlan hozzáférések laboratóriumokhoz, gépekhez, berendezésekhez (betörés, kulcsmásolat készítés, beléptető rendszer kijátszása stb.). II. Logikai fenyegetések Felhasználók felelőtlensége, tévedése (pl. meggondolatlan törlések: del *.*). Jogosult szolgáltatás megtagadás valamilyen probléma miatt. (Pl. garantált válaszidőt meghalad a szolgáltatás, és ennek jogi, gazdasági következményei vannak, eszköz tönkremenetel miatt adatvesztés és biztonsági másolatok nincsenek stb.). Jogosulatlan hozzáférések erőforrásokhoz, információkhoz, szolgáltatásokhoz. Ezen belül érdemes külön kezelni a következő osztályokat: 1. felhasználók kíváncsisága, jogosultsági határainak kipróbálása, a biztonsági háló lyukainak keresésére tett próbálkozások;
6 2. behatolás károkozási szándékkal, a biztonsági háló lyukainak felhasználása kártevő módon: copyright sértés, információ eltulajdonítás, kémkedés, személyiségi jogok sértése, "gépi idő" lopás, információk törlése, baktérium-vírus-worms programok készítése és terjesztése, stb. A felhasználók tévedései ellen alig szoktak központilag szervezetten védekezni, bár a rendszeres, központilag szervezett mentések itt is segíthetnek. Vegye mindenki figyelembe a régi közmondást: Don't put all your eggs in one basket! Azaz: Célszerű biztonsági másolatokat készíteni és azokat "más " helyen őrizni!
7 A hivatkozás figyelés (Reference Monitor) koncepció. A Reference Monitor koncepció a 60-as években kidolgozott koncepció, a több felhasználós számítógéprendszerek "hozzáféréses" típusú védelmi problémáinak megoldására. A koncepció lényege a fenti ábrán foglalható össze.
8 Subjects: aktív entitások, melyek objektumokat tudnak "elérni". Ide tartoznak a felhasználók, a processzek, taskok, job-ok. Objects: passzív entitások, erőforrások, szolgáltatások. Ilyenek pl. a számítógépek, CPU-k, a memóriák, eszközök, fájlok, programok stb. Reference Monitor Data Base: definiált biztonsági követelmények, azaz mely szubjektumok, kinek az érdekében, mely objektumokhoz, hogyan férhetnek hozzá. Security Audit (biztonsági figyelő, watchdog): a hozzáférési kísérletek (sikertelen/sikeres) naplózása, riasztás. Reference Monitor: a rendszer központi eleme. Bármilyen szubjektum, ha egy objektumhoz akar férni, csakis a Reference Monitor-on keresztül férhet hozzá. Ez azonosítja a szubjektumot (authentication), és leellenőrzi a Reference Monitor Data Base-n át a hozzáférés jogosultságot (authorisation). A hivatkozás figyelés koncepció - egyetlen közös adatbázissal - sohasem valósult meg, de részei szinte minden rendszerben megtalálhatók.
9 Alapfogalmak Az azonosítás (authentication) A szubjektumok (a felhasználók és a felhasználók nevében eljáró processzusok) azonosítandók. Az azonosítás célja megmondani, hogy a szubjektum mely védelmi tartományba (protection domain) tartozik. A felhasználók azonosítására vannak külső és belső azonosítási technikák. Pl. külső azonosítási lehetőség: mágneskártyás vagy vonalkódos engedélyeztető rendszer, gépet, szobát lezáró kulcs stb. Belső azonosítási technika pl. a jelszós (password) védelem, vagy néhány, csakis a felhasználó által ismert információ (pl. gyermekkori barátjának beceneve, stb.) lekérdezése egy rövid dialógusban. Jellegzetes problémakör a jelszós azonosítás problémaköre, ez ugyan egy kiváló azonosítási lehetőség, de egyben egy lehetséges lyuk a biztonsági hálón.
10 A hozzáférési jogosultságok (authorisation) Objektumok (erőforrások) elérése, ezekhez való hozzáférések privilégiumainak gyűjtőneve az authorisation. Pl.: Fájlokat (ezek objektumok) lehet olvasni r (read), írni, újraírni w, rw (write, rewrite), lehet tartalmukhoz hozzáfűzni a (append), lehet azokat törölni d (delete), végrehajtani x (exec). Számítógépeken, CPU-n lehet alkalmazásokat, rendszerprogramokat futtatni. Eszközökhöz is lehetnek hozzáférések, nagyrészt hasonlóak a fájlokhoz való hozzáférésekhez (r, w, rw, a, d).
11 Pl.: Üzenetsorokba lehet üzeneteket elhelyezni, onnan kiolvasni, lehet üzenetsort megszüntetni: ezek is jelezhetők a w, r, d betűkkel. A védelmi tartomány (Protection Domain) Def: a védelmi tartomány a védett erőforrások hozzáférési privilégiumainak összessége. Pl: MS-DOS védelmi tartomány MS-DOS command.com program futtatásánál: semmi autentikáció nem volt (bárki bekapcsolhat a gépet és ezzel indíthat a command.com programot), az MS-DOS elindításával "beléptünk" a védelmi tartományába. A command.com védelmi tartománya a legtöbb fájlhoz törlési jogot ad, de az IO.SYS és az MSDOS.SYS fájlokhoz ebben a tartományban nincs törlési jog. A del paranccsal (ez része a command.com-nak) nem lehet ezeket törölni. Ugyanebben a tartományban a PRN eszközhöz sincs delete jog, írás jog viszont van hozzá!
12 Unix példa a védelmi tartományokra Az uid (User ID) és gid (Group ID)- melyek meghatározzák (authentication) ki vagy te és mely csoportba tartozol - védelmi tartományokat is meghatároznak. A következő két tartományosztályról lehet szó: az uid-dal azonosított tartomány (a felhasználóval azonosított védelmi tartomány), a gid-del azonosított tartomány (a felhasználói csoport védelmi tartománya). Hány védelmi tartomány van a Unix-ban? Elég sok: ahány felhasználói uid létezik, ahány gid létezik,
13 legalább annyi védelmi tartomány van. Lehetségesek az uid/gid párokkal meghatározott védelmi tartományokon kívüli tartományok? A processzusok egy vagy több védelmi tartományba futnak! Az authentikáció célja éppen megmondani, mely védelmi tartomány(ok)ban fut egy folyamat. Az erőforrások (objektumok) egy vagy több védelmi tartományhoz tartoznak. A védelmi tartomány megmondja (meghatározza) a hozzáférési jogokat.
14 Hozzáférési jogok, listák, mátrixok A védelmi hálók leírásának két, különböző szervezettségű formája lehetséges. Az egyik a hozzáférési jogok listája (Access Control List, ACL), rövidebben hozzáférési lista (Access List), a másik a jogosultsági listák (Capability List, CL) formája. Mindkettőt mátrixok formájában is lehet ábrázolni (Access Matrix, AM). A jogosultság úgy tekinthető, mint egy meghívó egy bálra, a meghívót bemutatva beléphetünk, míg a hozzáférési lista egy bál meghívottainak névsora, a belépéskor azt ellenőrzik, rajta vagyunk-e a listán. Hozzáférési lista A forma lényege, hogy maga az objektum - hozzákapcsolt attribútumokkal - tárolja védelmi tartomány azonosítási lehetőséget és az objektumhoz való hozzáférési jogokat. Logikailag a lista "sorokból" áll. Sorai az objektumok,
15 hozzá felsorolva, mely védelmi tartományban milyen hozzáférési jogok vannak: CPU1: (PD1: x, PD2: x,...pdi: x,...pdn: x)... mem1: (PD1:rwx)... file1: (PD1:rwx, PD2: rw) file2: (PD1:r, PD2: rw,... PDi: r,... PDn: r)... itt a PDi - a Process Descriptor. A hozzáférések ellenőrzéséhez a folyamatokról csak annyit kell tudni, hogy az melyik védelmi tartományban fut. Ennek a formának előnye, hogy az ACL viszonylag rövid lista, többnyire könnyen kezelhető. Hátránya, hogy a lista sorok változó hosszúságúak lehetnek, fájl rendszerre nagyon hosszúak és itt már nehezen kezelhetőek. ACL jellegű a Unix (fájl) védelmi rendszere, a Windows NT védelmi hálója, a VAX/VMS fájl- és eszköz védelmi rendszere,
16 a bitmintákkal védett valós címzésű memória partíciókkal dolgozó memória menedzsment memóriavédelme (pl. IBM 360) stb. A jogosultsági lista Ez a forma - meglehetősen régi - egyre nagyobb jelentőségű: osztott rendszerekben, hálózatokban lehetetlen a védelmi tartományokat (akár a szegregációval egyszerűsített ACL-eket is) tárolni. Def: a jogosultsági lista az engedélyezett műveletek jegyzéke. A forma: sorok az egyes védelmi tartományokhoz, bennük felsorolva az objektumok és a hozzáférési jogok: PD1: (CPU1: x, mem1: rwx, file1: rwx, file2: r,... ) PD2: (CPU1: x, file1: r, file2: rw,...)... PDi: (CPU1: x, file2: r,...)... PDn: (CPU1: x, file2: r,...)
17 A jogosultság (capability) fogalmat kell megértenünk, ez azt jelenti, hogy egy processzus mit csinálhat az objektummal. Ha nincs jogosultsága, akkor nem érheti el. A processzushoz kapcsolódnak a jogosultságok, a processzusnak van jogosultsági listája (hiszen a processzus egy vagy több védelmi tartományban fut, azok jogosultságai vannak a processzushoz rendelve). Tehát nem az objektumok attribútumai tárolják a hozzáférési kódokat, hanem a processzusokhoz rendelik a jogosultságokat. Tipikus példa erre a felhasználói mód - kernel mód váltás: a processzushoz más jogosultság kapcsolódik a váltással. Másik tipikus példa a valós címzésű, memória partíciókkal gazdálkodó rendszerek esetén a partíció határokat regiszterekben tároló memória védelmi rendszer: miután a regiszterértékek a processzus kontextusához tartoznak, a processzushoz kapcsolódik a "jogosultság" ellenőrzési információ.
18 Egy processzus átadhatja a "jogosultságát" egy másik processzusnak, ekkor a másik processzusnak is lesz jogosultsága a objektumhoz, a jogosultság felíródik a processzus jogosultsági listájára. Természetesen ekkor a szokásos jogosultságokon (rwx, d, a) kívül további "jogosultságok-kal" (jogosultság átadási jog: grant, jogosultság átvételi jog: take) is kell foglakozni, ezek explicite vagy implicite benne kell legyenek a rendszerben.
19 A védelmi politika 1. Először a hozzáférni akaró processzus effektív tulajdonosági kódja és a fájl tulajdonossági kódja összevetődik. Ha itt egyezés van, akkor a fájltulajdonoshoz rendelt jogosultság (rwx bitminta) szerint biztosított a hozzáférés. 2. Ha az előző összevetésben nincs egyezés, akkor a csoport tulajdonosságok vetődnek össze (a processzus effektív csoport tulajdonos kódja!). Egyezés esetén a fájl INODE táblázata szerinti a hozzáférés. 3. Ha az előző két összevetés "sikertelen", akkor az others bitminta szabja meg a hozzáférést. Ez azt jelenti, hogy tulajdonos hozzáférését a fájlvédelmi minta tulajdonos része határozza meg, hiába van nagyobb jog akár a csoport, akár az others bitmintában. Egy fájl, aminek védelmi mintája a következő ---r--rwx
20 nem elérhető a tulajdonos számára (első három -, azaz ---), a csoport tagjai ugyan olvashatják (r--), de nem írhatják, se futathatják, emellett mindenki más, aki nem tartozik a csoporthoz teljes hozzáféréssel rendelkezik (rwx olvasás, írás, futtatás). Ezért ez a hozzáférési lista nem valami hasznos! A setuid koncepció (D. Ritchie) Minden processzus rendelkezik valós tulajdonosi, csoporttulajdonosi azonosítóval, és effektív tulajdonosi, csoporttulajdonosi azonosítóval. A legtöbb esetben a valós és az effektív tulajdonosságok ugyanazok. A valós tulajdonosságot a processzus a szülőjétől örökli, vagy a szülője állítja be neki. Gyakran szükség van arra, hogy különleges többlet-jogokat biztosítsunk processzusoknak valamilyen szabályozott módon.
21 Például, ha jelszót változtatunk a passwd segédprogrammal, be kell írnunk a jelszavakat tartalmazó fájlba, amire persze nekünk nem lehet írási jogunk, mert akkor bárkinek a jelszavát átírhatnánk, kitörölhetnénk stb. Hogyan lehet megoldani ezt a problémát? D. Ritchie javaslatára, a kernel megengedi, hogy olyan processzusokat kreáljunk, amelyeknek többletjoguk van. Bizonyos végrehajtható fájlok ún. setuid/setgid (Set User Identification/Set Group ID) engedéllyel rendelkeznek (lásd man ls). Amikor egy ilyen programot futtatunk, a keletkezett processzus valós tulajdonosa mi leszünk (valós csoport tulajdonosa a mi csoportunk), hiszen a mi shell-ünkből indítottuk, annak tulajdonosságait örökli. Az effektív tulajdonosa/csoporttulajdonosa viszont az az uid/gid lesz, ami a betöltendő program fájlhoz tartozik. A fenti példában passwd futtatható program tulajdonosa a root (superuser), ez egyben setuid program. Ha futtatjuk, a processzus valós tulajdonosa mi vagyunk, effektív tulajdonosa viszont a root. Mivel a jelszavakat tartalmazó fájl tulajdonosa szintén a root, a processzus kicserélhet jelszavunkat, írhatja a fájlt.