Kan någon hjälpa mig att reda ut några saker med .Net säkerhet?

Jag förstår att man kan använd sig av .assert för att få reda på om man har tillgång till en viss resurs men varför vill man använda deny? Är det för att öka säkerheten innan man skall köra okänd kod? Är då inte detta snarare något för operativet att hålla reda på?

Dessutom är det en sak som förvillar mig mellan JIT och run-time. Antag till exempel att jag har en assembly som anropar native kod.
Jag lägger då till följande attribut:
[assembly:SecurityPermission(SecurityAction::RequestMinimum, UnmanagedCode = true)];

Är det inte då så att när assembly:t laddas så kollar JIT-kompilatorn att den assembly som skall använda sig av min assembly har tillåtelse att köra unmanaged kod?

Varför behöver då run-time kolla detta varje gång unmanaged kod anropas?

Man kan dessutom ge native-funktioner attributet "SuppressUnmanagedCodeSecurityAttribute" vilket stänger av kontrollen. Om jag då skulle skriva skadlig kod skulle jag ju sätta detta på alla funktioner jag anropar och därmed gå runt evetuell tidigare deny.

Är assert det bästa sätta att kolla om man har en viss rättighet? Är det inte bättre att försöka göra det man vill och låta det generera ett securityexception om det inte går? Annars måste väl säkerhetstestet göras två gånger (en gång av mig och en gång av run-time)?

Jag måste ha missat något fundamentalt när det gäller .Net säkerhet.

Någon som vet om C++/CLI automatiskt lägger till attributet "SuppressUnmanagedCodeSecurityAttribute" på nativefunktioner? Hur bär man sig annars åt för att göra det (IJW lägger ju till nativefunktionerna med automatik).

Edit: Menar förståss demand och inte assert. Hittade också svaret på C++/CLI frågan (Ja)

Finessen är väl att du kan försäkra operativet (som får möjlighet att försäkra användaren) att din .exe inte kommer göra något dumt som att t.ex. skapa konstiga DLL-filer i system32-mappen, genom att explicit förbjuda sig själv åtkomst dit. Visst är det operativet som ska se till att säkerhetsprinciperna följs, men genom .Net-säkerheten berättar du för operativet vad koden gör resp. inte gör. T.ex. ett företagsnätverk kan ha principen att förbjuda start av osignade exe-filer som inte talar om/garanterar var på disken den kommer att skriva. Men om din assembly berättar för operativet att "tjena, jag vill ha ett stort hänglås på hårddisken" (deny) då får koden köras utan protester. Jag har lyckats undvika unmanaged code, så jag kan inte svara på den delen av frågan :)

>T.ex. ett företagsnätverk kan ha principen att förbjuda start av osignade exe-filer som inte talar
>om/garanterar var på disken den kommer att skriva.

>Men om din assembly berättar för operativet att "tjena, jag vill ha ett stort hänglås på hårddisken"
>(deny) då får koden köras utan protester.

Jo men det gör man ju på assemblynivå, dvs assembly:SecurityPermission...

"Deny" gäller ju bara kod som anropas _från_ den funktion där jag sätter den.

(Tycker bara det är konstigt att alla exempel på .net säkerhet visar hur man gör deny men inte förklarar varför man skulle vilja göra det)

Man vill göra det av den anledning jag förklarade. Du försäkrar genom deny att din metod inte kan göra något dåligt. Och man kan dessutom alltså göra det på metodanropsnivå om man vill.
Så att appen kan starta, och exception uppstår först när ett sådant anrop sker.

Jag är antagligen trög men jag förstår fortfarande inte.

Låt mig ta ett exempel.
<code>
void minmetod() {
// skapa write-permission till C:\Temp
FileIOPermission perm = new FileIOPermission(FileIOPermissionAccess.Write, @"C:\Temp");
// Se nu till att jag inte kan skriva i C:\Temp
perm.Deny();
// Varje skrivning till C:\Temp genererar nu en securityexception
...
// När metoden avslutas är det fritt fram att skriva till C:\temp igen
}
</code>

>Du försäkrar genom deny att din metod inte kan göra något dåligt.

Jo, men jag försäkrar det ju enbart internt i min metod. Utomstående funktioner som anropar min metod vet ju inte om det.
Dessutom känns det lite konstigt att lista saker som min metod får eller inte får göra. Kan tänka mig att metoden gör olika saker beroende på vilka rättigheter som finns men det löser man väl bäst med security exceptions:
<code>
try {
// read from HKLM
}
catch (SecurityException) {
try {
// nähä, det gick inte, försök läsa från HKCU istället
...
</code>

>Så att appen kan starta, och exception uppstår först när ett sådant anrop sker.

Det är här jag får problem. Om appen kan starta eller inte styrs väl av vilka assemblyattribut som är satta inte vad den gör i olika metoder? Om jag till exempel gör så här:

[assembly:FileIOPermissionAttribute(RequestMinimum, Write=@"C:\Temp")]

så kan min assembly inte starta om anroparen inte har skrivrättigheter i C:\Temp.

Men om jag inte sätter attributet ovan och anroparen inte har skrivrättigheter i C:\Temp och jag skriver där så blir det ett security exception lite senare. Vad är skillnaden?

Ok jag missförstod dig lite. Jag menade att du kan sätta sådana attribut även på dina egna klasser internt i appen samt dess metoder. Enligt MSDN: Allows security actions for FileIOPermission to be applied to code using declarative security.

Altså kan du genom detta försäkra anroparen / operativet att en viss metod som ska köras inte kan göra något dumt och man skulle kunna sätta upp säkerheten i operativet så att man inte tillåter kod som inte utlovar hög säkerhet.