• 03/30/2017
• 6 perc olvasás
• • g
  • D
  • m
  • Y

  .

  • s
  • +8

A biztonság három, egymással kölcsönhatásban álló részből áll: sandboxing, jogosultságok és végrehajtás. A homokdobozolás az elszigetelt tartományok létrehozásának gyakorlatára utal, ahol egyes kódokat teljesen megbízhatónak kezelnek, más kódokat pedig a homokdobozhoz beállított jogosultságokra korlátoznak. A homokdoboz engedélykészletén belül futó alkalmazáskód átláthatónak tekinthető, azaz nem végezhet olyan műveleteket, amelyek befolyásolhatják a biztonságot. A sandbox engedélykészletét a bizonyítékok (Evidence osztály) határozzák meg. Az evidencia határozza meg, hogy milyen konkrét jogosultságokra van szükség a homokdobozokhoz, és milyen típusú homokdobozok hozhatók létre. Az érvényesítés arra utal, hogy az átlátható kódot csak az adott engedélyezési készleten belül engedi végrehajtani.

A transzparencia modell célja

A transzparencia egy olyan végrehajtási mechanizmus, amely elválasztja az alkalmazás részeként futó kódot az infrastruktúra részeként futó kódtól. Az átláthatóság határt húz a kiváltságos dolgokat (kritikus kód), például a natív kód meghívását végző kód és az erre nem képes kód (átlátható kód) közé. Az átlátható kód az általa használt jogosultságkészlet határain belül hajthat végre parancsokat, de nem hajthat végre kritikus kódot, nem származhat belőle, és nem tartalmazhat kritikus kódot.

A transzparencia érvényesítésének elsődleges célja, hogy egyszerű és hatékony mechanizmust biztosítson a különböző kódcsoportok jogosultságok alapján történő elkülönítésére. A sandboxing modell kontextusában ezek a jogosultsági csoportok vagy teljesen megbízhatóak (azaz nem korlátozottak), vagy részben megbízhatóak (azaz a sandboxnak adott jogosultságkészletre korlátozottak).

A transzparenciát a .NET Framework 2.0-s verziójában vezették be a biztonsági modell egyszerűsítése, valamint a biztonságos könyvtárak és alkalmazások írásának és telepítésének megkönnyítése érdekében. Az átlátható kódot a Microsoft Silverlight is használja, hogy egyszerűsítse a részben megbízható alkalmazások fejlesztését.

Átláthatósági szint meghatározása

A assembly-szintű SecurityRulesAttribute attribútum kifejezetten kiválasztja azokat a SecurityRuleSet szabályokat, amelyeket a assembly követni fog. A szabályok egy numerikus szintű rendszerbe vannak rendezve, ahol a magasabb szintek a biztonsági szabályok szigorúbb érvényesítését jelentik.

A szintek a következők:

• Level 2 (Level2) – a .NET Framework 4 átláthatósági szabályai.

• Level 1 (Level1) – a .NET Framework 2.0 átláthatósági szabályai.

A két átláthatósági szint közötti elsődleges különbség az, hogy az 1. szint nem érvényesíti az átláthatósági szabályokat az összeállításon kívülről érkező hívásokra, és csak kompatibilitási célokat szolgál.

Level 2 Transparency

A 2. szintű átláthatóság a .NET Framework 4-ben került bevezetésre. Ennek a modellnek a három alapelve az átlátható kód, a biztonsági szempontból biztonságos kritikus kód és a biztonsági szempontból kritikus kód.

• A transzparens kód, függetlenül a neki adott jogosultságoktól (beleértve a teljes bizalmat), csak más transzparens kódot vagy biztonsági szempontból biztonságos kritikus kódot hívhat. Ha a kód részben megbízható, akkor csak olyan műveleteket hajthat végre, amelyeket a tartomány engedélykészlete megenged. Az átlátható kód a következőket nem teheti meg:

  • Megállapítási műveletet vagy jogosultságnövelést végezhet.

  • Biztonságtalan vagy ellenőrizhetetlen kódot tartalmazhat.

  • Kritikus kód közvetlen hívása.

  • Natív kód vagy a SuppressUnmanagedCodeSecurityAttribute attribútummal rendelkező kód hívása.

  • Hívjon olyan tagot, amely LinkDemand által védett.

  • Kritikus típusokból való öröklés.

    Az átlátható módszerek továbbá nem írhatják felül a kritikus virtuális módszereket, és nem implementálhatnak kritikus interfészmódszereket.

  • A biztonsági szempontból biztonságos-kritikus kód teljesen megbízható, de az átlátható kód által hívható. A teljesen megbízható kód korlátozott felületét tárja fel. A helyesség és a biztonsági ellenőrzések a biztonságos-kritikus kódban történnek.

  • A biztonságkritikus kód bármilyen kódot meghívhat, és teljesen megbízható, de átlátható kód nem hívhatja meg.

  1. szintű átláthatóság

  Az 1. szintű átláthatósági modellt a .NET Framework 2.0 verziójában vezették be, hogy a fejlesztők csökkenthessék a biztonsági ellenőrzésnek kitett kód mennyiségét. Bár az 1. szintű átláthatóság a 2.0-s verzióban nyilvánosan elérhető volt, elsősorban csak a Microsofton belül használták biztonsági auditálási célokra. A megjegyzéseken keresztül a fejlesztők kijelölhetik, hogy mely típusok és tagok végezhetnek biztonsági emeléseket és egyéb megbízható műveleteket (biztonsági szempontból kritikusak), és melyek nem (biztonsági szempontból átláthatók). Az átláthatónak minősített kód nem igényel nagyfokú biztonsági ellenőrzést. Az 1. szintű átláthatóság azt jelenti, hogy az átláthatóság érvényesítése az összeállításon belülre korlátozódik. Más szóval, a biztonságkritikusként azonosított nyilvános típusok vagy tagok csak az összeállításon belül biztonságkritikusak. Ha ezeknek a típusoknak és tagoknak a biztonságát az összeállításon kívülről történő meghívásukkor is érvényesíteni kívánja, akkor a teljes bizalomra vonatkozó linkkövetelményeket kell használnia. Ha ezt nem teszi, a nyilvánosan látható biztonságkritikus típusok és tagok biztonsági szempontból kritikusnak tekintendők, és az assemblyn kívüli, részben megbízható kód által meghívhatók.

  Az 1. szintű átláthatósági modell a következő korlátozásokkal rendelkezik:

  • A biztonságkritikus típusok és tagok, amelyek nyilvánosak, biztonsági szempontból átlátszó kódból elérhetők.

  • Az átláthatósági megjegyzések csak az assemblyn belül érvényesülnek.

  • A biztonságkritikus típusoknak és tagoknak linkkövetelményekkel kell érvényesíteniük a biztonságot az assemblyn kívülről történő hívások esetén.

  • Az öröklési szabályok nem érvényesülnek.

  • Létezik annak a lehetősége, hogy az átlátható kód teljes bizalommal futtatva káros dolgokat végezzen.

  Átláthatóság érvényesítése

  Az átláthatósági szabályok nem érvényesülnek, amíg az átláthatóság kiszámítása nem történik meg. Ekkor egy InvalidOperationException-t dob, ha egy átláthatósági szabály sérül. Az átláthatóság kiszámításának ideje több tényezőtől függ, és nem lehet megjósolni. A számítás a lehető legvégső időpontban történik. A .NET Framework 4-ben a szerelvényszintű átláthatóság kiszámítása hamarabb történik, mint a .NET Framework 2.0-ban. Az egyetlen garancia az, hogy az átláthatóság kiszámítása a szükséges időpontban megtörténik. Ez hasonló ahhoz, ahogyan a just-in-time (JIT) fordító megváltoztathatja azt a pontot, amikor egy metódus lefordításra kerül, és a metódusban lévő hibákat észleli. Az átláthatóság-számítás láthatatlan, ha a kódban nincsenek átláthatósági hibák.

  Lásd még

  • Biztonsági szempontból átlátszó kód, 1. szint
  • Biztonsági szempontból átlátszó kód, 2. szint

  .