SecurityException bei Zugriff über LAN

SecurityException bei Zugriff über LAN
Frank Dzaebel, erstellt am: 16.11.2005, zuletzt geändert: 19.7.2008
Kategorie: Sicherheit, .NET-Version: 1.1/2.0

Vielfach möchte man unter dem .NET Framework eine Exe (Assembly) über das Netzwerk aufrufen. Dies ist aber standardmässig gesperrt, erst ab dem .NET Framework 3.5 SP1 wird einer Assembly wieder FullTrust gegeben, wenn sie über eine Netzwerkfreigabe aufgerufen wird. Hier die verschiedenen Möglichkeiten, dies zu ermöglichen:

Gründe für die Sperrung in älteren Frameworks (SD3+C - Richtlinie)
[Secure by Design/Default/Deployment and Communications] [Der Sicherheits-Entwicklungszyklus bei Microsoft]
Allgemeine C# Security How-To's: [Sicherheit (Vorgehensweise in C#)]

1) Anwendungen mit dem .NET 3.5 SP1 schreiben und aufrufen.
[FullTrust on the LocalIntranet]

2) Der Nutzer kann durch eine Batch-Datei oder Assembly explizit vertrauen:
   [Full Trust für Assemblies mit caspol.exe]
   [Full Trust für Assemblies per Sourcecode]
   [Verwaltung der Sicherheitsrichtlinien]
Das Tool "caspol.exe" kommt aber mit dem .NET Framework:
[Code Access Security Policy-Tool (Caspol.exe)]

3) Der Nutzer kann dieser Assembly manuell explizit vertrauen über ein SnapIn.
Unter .NET 2.0 wird dieses SnapIn nur durch das SDK 2.0 installiert.
Unter .NET 1.1 aufgerufen über "%Systemroot%/Microsoft.NET/Framework/<VersionsNummer>/Mscorcfg.msc"
[.NET Framework Konfigurationstool (Mscorcfg.msc)]
   [.NET Programme vom Netzlaufwerk starten]

4) Oder gar dem gleich dem ganzen Intranet vertrauen. Beachten Sie ggf. die Vista64-Richtlinien.

5) Oder nur Assemblies mit Deinem "Strong Name" zulassen (IMHO anzustrebender Weg)
[Michael Willers, CAS] [Neno Loje, Strong Name anstatt FullTrust]

Weitere Hintergründe:
[MSDN CAS Tools & Best Practices] 12.2.2007
- [Code Access Security (engl.), PDF, XPS] -> siehe: Kapitel 4.1 Starting an Application from Network
- [Common Policy Scenarios (engl.), PDF, XPS]
- [CAS Tools]

[Artikel-Serie „Code Access Security“]
Teil 1: Was darf mein Code? - Das Sicherheitsmodell der Common Language Runtime
Teil 2: Sandkastenspiele. Deployment von Sicherheitsrichtlinien für die Common Language Runtime