Sollte ich meinen Sicherheitscode mit meinem unsicheren Code mischen?

Question

Ich arbeite an einem Projekt, das eine Reihe von WIN32-API-Aufrufe verwendet und einigen unsicheren Code erfordert. Aus der Sicht der besten Praktiken sollte ich diesen Code in seiner eigenen DLL, kompiliert mit/unsafe Switch, isolieren, während meine Hauptanwendung sicher bleibt?

Um es anders auszudrücken. Gibt es einen Grund, kein Projekt mit dem Schalter/unsafe zu kompilieren? Gibt es potenzielle Risiken?

Answer 1

Eine Assembly ist definitionsgemäß die kleinste Einheit von unabhängig versionierbarem, weitervertreibbarem Code in .NET. Die erste Frage, die ich mir stellen möchte, lautet: "Will ich jemals eine neue Version des unsicheren Codes erstellen und sie unabhängig von meiner Anwendung verteilen?"

Wenn die Antwort ja ist, dann fügen Sie diesen Code auf jeden Fall in eine eigene Baugruppe ein.

Wenn die Antwort nein ist, dann berücksichtigen Sie andere Faktoren. Beispielsweise können Sie in der "klassischen" .NET-Sicherheit verschiedene Assemblys auf verschiedenen Vertrauensstufen in derselben App-Domäne ausführen. (In der modernen CLR ist das System viel einfacher, es gibt nur voll vertrauenswürdigen Code und alles andere läuft auf der Vertrauensstufe der App-Domain.) Ihr Code, der etwas unsicher macht, muss voll vertrauenswürdig sein, aber der Code, der einfach aufruft Es könnte weniger vertrauenswürdig sein, wenn der unsichere Code den richtigen Berechtigungssatz aktiviert.

Werden Sie jemals in einer Situation sein, in der Ihr Sicherheitscode teilweise vertrauenswürdig ist? Ist dies der Fall, dann fügen Sie den unsicheren Code unbedingt in eine eigene Assembly ein und dokumentieren Sie, dass diese Assembly vollständig vertrauenswürdig ist.

Wenn Sie nicht in solchen Situationen sind, dann wäre ich nicht geneigt, meinen unsicheren Code in eine eigene Assembly zu legen.

Ich würde jedoch geneigt sein, ein angenehmes verwaltetes Objektmodell über meinen nicht verwalteten Code zu schreiben, anstatt nur rohe win32-Aufrufe offenzulegen. Zum Beispiel, neulich musste ich einige der starken Namensverifikation win32 apis von C# aufrufen und ich habe gerade eine kleine Bibliothek aufgepeitscht, die sie schön entblößte und alle fiesen Interop-Details im privaten Inneren der Klasse abstrahierte.