- 30/03/2017
- 6 minuter att läsa
-
-
g -
D -
m -
Y -
s -
+8
-
Försiktighet
Code Access Security (CAS) och partiellt betrodd kod
Den .NET Framework tillhandahåller en mekanism för att upprätthålla olika nivåer av förtroende för olika koder som körs i samma program som kallas Code Access Security (CAS).
CAS stöds inte i .NET Core, .NET 5 eller senare versioner. CAS stöds inte av versioner av C# senare än 7.0.
CAS i .NET Framework bör inte användas som en mekanism för att upprätthålla säkerhetsgränser baserade på kodursprung eller andra identitetsaspekter. CAS och Security-Transparent Code stöds inte som en säkerhetsgräns med delvis betrodd kod, särskilt kod med okänt ursprung. Vi avråder från att ladda och exekvera kod av okänt ursprung utan att vidta alternativa säkerhetsåtgärder. .NET Framework kommer inte att utfärda säkerhetspatchar för eventuella utnyttjanden med höjda privilegier som kan upptäckas mot CAS-sandlådan.
Denna policy gäller alla versioner av .NET Framework, men gäller inte .NET Framework som ingår i Silverlight.
Säkerheten består av tre delar som samverkar: sandlådor, behörigheter och verkställighet. Sandboxing innebär att man skapar isolerade domäner där en del kod behandlas som helt betrodd och annan kod är begränsad till de behörigheter som anges i den beviljade inställningen för sandlådan. Applikationskoden som körs inom sandlådans behörighetsuppsättning anses vara transparent, dvs. den kan inte utföra några operationer som kan påverka säkerheten. Sandlådans behörighetsuppsättning bestäms av bevis (Evidence class). Bevismaterial identifierar vilka specifika behörigheter som krävs för sandlådor och vilka typer av sandlådor som kan skapas. Med verkställighet menas att transparent kod endast får exekveras inom sin tilldelningsuppsättning.
Viktigt
Säkerhetspolicy var en viktig del i tidigare versioner av .NET Framework. Från och med .NET Framework 4 är säkerhetspolicyn föråldrad. Avskaffandet av säkerhetspolicyn är skilt från säkerhetsgenomskinlighet. För information om effekterna av den här ändringen, se Kompatibilitet och migration av säkerhetspolicy för kodåtkomst.
Transparensmodellens syfte
Transparens är en verkställighetsmekanism som skiljer kod som körs som en del av programmet från kod som körs som en del av infrastrukturen. Transparens drar en barriär mellan kod som kan göra privilegierade saker (kritisk kod), t.ex. anropa inhemsk kod, och kod som inte kan göra det (transparent kod). Transparent kod kan utföra kommandon inom gränserna för den behörighetsuppsättning den arbetar i, men kan inte utföra, härleda från eller innehålla kritisk kod.
Det primära målet med verkställandet av transparens är att tillhandahålla en enkel och effektiv mekanism för att isolera olika grupper av kod baserat på privilegier. Inom ramen för sandlådemodellen är dessa privilegiegrupper antingen helt betrodda (dvs. inte begränsade) eller delvis betrodda (dvs. begränsade till den behörighetsuppsättning som beviljats sandlådan).
Viktigt
Transparensmodellen överskrider säkerheten för kodåtkomst. Transparens upprätthålls av just-in-time-kompilatorn och förblir i kraft oavsett vilken behörighetsuppsättning som gäller för en samling, inklusive fullt förtroende.
Transparens infördes i .NET Framework version 2.0 för att förenkla säkerhetsmodellen och för att göra det lättare att skriva och distribuera säkra bibliotek och tillämpningar. Transparent kod används också i Microsoft Silverlight för att förenkla utvecklingen av delvis betrodda tillämpningar.
Note
När du utvecklar en delvis betrodd tillämpning måste du vara medveten om behörighetskraven för dina målvärdar. Du kan utveckla en applikation som använder resurser som inte tillåts av vissa värdar. Den här applikationen kommer att kompileras utan fel, men kommer att misslyckas när den laddas i värdmiljön. Om du har utvecklat programmet med Visual Studio kan du aktivera felsökning i partiellt förtroende eller i en begränsad behörighetsuppsättning från utvecklingsmiljön. Mer information finns i Hur man gör: Debugga en ClickOnce-applikation med begränsade behörigheter. Funktionen Beräkna behörigheter som tillhandahålls för ClickOnce-tillämpningar är också tillgänglig för alla delvis betrodda tillämpningar.
Specificera transparensnivån
Attributet SecurityRulesAttribute på sammansättningsnivå väljer explicit de SecurityRuleSet-regler som sammansättningen ska följa. Reglerna är organiserade enligt ett numeriskt nivåsystem, där högre nivåer innebär striktare tillämpning av säkerhetsreglerna.
Nivåerna är följande:
Nivå 2 (Level2) – .NET Framework 4:s transparensregler.
Nivå 1 (Level1) – .NET Framework 2.0:s transparensregler.
Den främsta skillnaden mellan de två öppenhetsnivåerna är att nivå 1 inte tillämpar öppenhetsreglerna för anrop utanför samlingen och är endast avsedd för kompatibilitet.
Viktigt
Du bör ange transparensnivå 1 endast för kompatibilitet, det vill säga ange nivå 1 endast för kod som utvecklades med .NET Framework 3.5 eller tidigare som använder attributet AllowPartiallyTrustedCallersAttribute eller inte använder transparensmodellen. Använd till exempel transparensnivå 1 för .NET Framework 2.0-samlingar som tillåter anrop från delvis betrodda anropare (APTCA). För kod som utvecklas för .NET Framework 4, använd alltid nivå 2 transparens.
Nivå 2 transparens
Nivå 2 transparens infördes i .NET Framework 4. De tre principerna i denna modell är transparent kod, säkerhetskritisk kod och säkerhetskritisk kod.
Transparent kod kan, oavsett vilka behörigheter den har beviljats (inklusive fullt förtroende), endast anropa annan transparent kod eller säkerhetskritisk kod. Om koden är delvis betrodd kan den endast utföra åtgärder som är tillåtna enligt domänens behörighetsuppsättning. Transparent kod kan inte göra följande:
-
Göra en Assert-operation eller höja privilegier.
-
Innehåller osäker eller okontrollerbar kod.
-
Kalla direkt kritisk kod.
-
Kalla inhemsk kod eller kod som har attributet SuppressUnmanagedCodeSecurityAttribute.
-
Kalla en medlem som skyddas av ett LinkDemand.
-
Härva från kritiska typer.
Transparenta metoder kan dessutom inte åsidosätta kritiska virtuella metoder eller implementera kritiska gränssnittsmetoder.
Säkerhetssäker-kritisk kod är helt betrodd men kan kallas av transparent kod. Den exponerar en begränsad yta av kod med fullt förtroende. Korrekthets- och säkerhetskontroller sker i säker-kritisk kod.
Säkerhetskritisk kod kan anropa vilken kod som helst och är fullt betrodd, men den kan inte anropas av transparent kod.
Nivå 1 Transparens
Nivå 1-modellen för transparens infördes i .NET Framework version 2.0 för att göra det möjligt för utvecklare att minska den mängd kod som är föremål för en säkerhetsgranskning. Även om nivå 1-transparens var allmänt tillgänglig i version 2.0 användes den i första hand endast inom Microsoft för säkerhetsrevision. Med hjälp av anteckningar kan utvecklare ange vilka typer och medlemmar som kan utföra säkerhetshöjningar och andra betrodda åtgärder (säkerhetskritiska) och vilka som inte kan göra det (säkerhetstransparenta). Kod som identifieras som transparent kräver inte en hög grad av säkerhetsgranskning. Transparens på nivå 1 anger att tillämpningen av transparens är begränsad till att gälla inom samlingen. Med andra ord är alla offentliga typer eller medlemmar som identifieras som säkerhetskritiska endast säkerhetskritiska inom sammansättningen. Om du vill upprätthålla säkerheten för dessa typer och medlemmar när de anropas utanför sammanslutningen måste du använda länkkrav för fullt förtroende. Om du inte gör det behandlas offentligt synliga säkerhetskritiska typer och medlemmar som säkerhetskritiska och kan anropas av delvis betrodd kod utanför sammansättningen.
Den nivå 1 transparensmodellen har följande begränsningar:
-
Säkerhetskritiska typer och medlemmar som är offentliga är åtkomliga från säkerhetstransparent kod.
-
Transparensannotationerna upprätthålls endast inom en sammansättning.
-
Säkerhetskritiska typer och medlemmar måste använda länkkrav för att upprätthålla säkerheten för anrop utanför sammansättningen.
-
Säkerhetsreglerna för arv upprätthålls inte.
-
Det finns potential för transparent kod att göra skadliga saker när den körs i fullt förtroende.
- Säkerhetstransparent kod, nivå 1
- Säkerhetstransparent kod, nivå 2
Transparensgenomförande
Transparensreglerna genomdrivs inte förrän transparens beräknas. Vid den tidpunkten kastas ett InvalidOperationException om en transparensregel överträds. Den tid som transparensen beräknas beror på flera faktorer och kan inte förutsägas. Den beräknas så sent som möjligt. I .NET Framework 4 sker beräkningen av transparens på assemblernivå tidigare än i .NET Framework 2.0. Den enda garantin är att transparensberäkningen kommer att ske vid den tidpunkt då den behövs. Detta liknar hur JIT-kompilatorn (Just-in-time) kan ändra tidpunkten för när en metod kompileras och eventuella fel i den metoden upptäcks. Transparensberäkningen är osynlig om din kod inte har några transparensfel.
Se även
.