Sicherheit in Longhorn: Fokus auf die geringsten Rechte

Keith Brown
DevelopMentor

April 2004

Gilt für:
   2003 Professional Developers Conference (PDC) "Longhorn"-Vorschaubuild

Zusammenfassung: Longhorn verspricht, eine hervorragende Plattform für Anwendungen mit den geringsten Rechten zu sein. Beginnen Sie noch heute, indem Sie zunächst verwalteten Code schreiben. Stellen Sie beim Erstellen von Desktopanwendungen diese LUA-konform fest (und verwenden Sie die Windows-Anwendungsüberprüfung, um Ihre Arbeit zu überprüfen). (11 gedruckte Seiten)

Inhalte

Problemstellung
Anwendungs- und Bereitstellungsmanifeste
LUA: Benutzerkonto mit den geringsten Rechten
Die (veraltete) Gruppe "Power Users"
AIM: Application Impact Management
PA: Geschützter Administrator
Verwaltete Anwendungen auf Longhorn
Der Berechtigungssatz "Kein Risiko"
Tools
Zusammenfassung

Ich bin schon lange ein Verfechter des Laufens mit den geringsten Privilegien. Viele, die mich kennen, haben meine Äußerung gehört, dass Entwickler die Ausführung mit Administratorrechten beenden sollten, während sie Code entwickeln, und zwar nur, um zu fördern, dass mehr Anwendungen für die Ausführung in Umgebungen mit den geringsten Rechten geschrieben werden. Daher war ich sehr erfreut, auf der Microsoft Professional Developers Conference (PDC) 2003 zu hören, dass eines der Standard Ziele der nächsten Version des Windows-Betriebssystems®, code-name "Longhorn", es ist, es für Benutzer einfacher zu machen, mit den geringsten Berechtigungen auszuführen.

Problemstellung

Wenn Sie eine Kopie von Microsoft Windows XP® Professional in Ihrem lokalen Softwareshop kaufen und auf einem PC installieren, erstellt der Setup-Assistent Konten für Sie und alle anderen Benutzer, die den Computer verwenden werden. Nachdem Windows XP gestartet wurde, wird ein ziemlich willkommener Bildschirm angezeigt, auf dem der Name der einzelnen Benutzer angezeigt wird und der Benutzer sich anmelden kann. Jeder dieser Benutzer ist standardmäßig ein Administrator des Computers. Warum? Denn die Benutzererfahrung wäre schlecht, wenn es nicht so wäre.

Benutzer erwarten, dass sie Software auf ihren Computern installieren können, aber Sie können nur 90 Prozent der heutigen Software installieren, wenn Sie ein Administrator sind. Benutzer erwarten, dass Software ohne Absturz ausgeführt wird, aber 70 Prozent der Software werden nicht ordnungsgemäß ausgeführt, es sei denn, der Benutzer ist ein Administrator, was eine optimistische Zahl ist. Leider schlägt eine große Anzahl dieser Anwendungen in einer nicht administrativen Umgebung fehl, einfach weil sie schlechte Entscheidungen treffen, wo der Anwendungszustand gespeichert werden soll. Das Verzeichnis Programme ist nicht als Speicherort für den Zustand vorgesehen. Es ist ein Ort zum Speichern von Programmen – ausführbaren Dateien. Der Ort zum Speichern des Anwendungszustands wird als Benutzerprofil bezeichnet, und zum Speichern des freigegebenen Benutzerstatus reicht das Profil "Alle Benutzer" ziemlich gut aus. Die Richtlinien für das Windows-Logo-Programm erklären dies, aber die überwiegende Mehrheit der heutigen Windows-Software wurde ohne Berücksichtigung der Windows-Logo-Richtlinien entwickelt.

Aber warum, fragen Sie sich vielleicht, sollten Benutzer als Nicht-Administratoren ausführen möchten, insbesondere als Privatbenutzer? Nun, wenn es tatsächlich einfach wäre, würde der Heimbenutzer viele Vorteile nutzen. Schadsoftware (ein Virus, Wurm oder anderer bösartiger Code) hat gerne Administratorrechte. Das Surfen im Web oder das Lesen von E-Mails als Administrator ist heutzutage einfach gefährlich. Was ist mit Ihren Kindern? Wäre es nicht schön, ihnen zu erlauben, Spiele auf Ihrem Heimcomputer zu installieren und zu spielen, da sie wissen, dass sie nicht versehentlich etwas unterbrechen, Spyware installieren oder die Von Ihnen auferlegten Einschränkungen der Inhaltsbewertung entfernen? Stellen Sie sich dies wie folgt vor: Wenn Sie als Administrator ausgeführt werden, werden die meisten Sicherheitsschutzfunktionen von Windows effektiv deaktiviert. Privat- und Unternehmensbenutzer sollten diese Schutzmaßnahmen nicht deaktivieren, insbesondere wenn sie mit dem Internet verbunden sind, was zu einer ziemlich gefährlichen Nachbarschaft geworden ist.

Benutzer und die programme, die sie ausführen, um glücklich in einer Umgebung mit den geringsten Rechten zu leben, wird die Sicherheit der Windows-Plattform erheblich erhöhen.

Anwendungs- und Bereitstellungsmanifeste

Ein wichtiges Feature, das Longhorn einführt, ist das Konzept von Anwendungs- und Bereitstellungsmanifesten. Erstere ermöglicht Es Anwendungsentwicklern, die Berechtigungen anzugeben, die ihre Anwendung benötigt, um ordnungsgemäß zu funktionieren, und letzteres ermöglicht Es Administratoren, anzugeben, wie viel Vertrauen sie in die Anwendung setzen. Diese Manifeste haben noch viel mehr, aber ich möchte darauf hinweisen, dass sie sowohl für verwaltete als auch für nicht verwaltete Anwendungen gleichermaßen verfügbar sind, und dass ein wichtiger Grund für ihre Existenz darin besteht, Benutzern bei der Ausführung von Anwendungen mit den geringstmöglichen Berechtigungen zu helfen.

Um mehr über diese Manifeste zu erfahren, sehen Sie sich Kapitel 1 von Brent Rectors Buch Introducing "Longhorn" for Developers an.

LUA: Least-Privilege Benutzerkonto

LUA oder Benutzerkonto mit den geringsten Rechten ist ein Akronym, das von nun an immer wieder in Microsoft-Präsentationen angezeigt wird. Die PDC 2003-Referenten sprachen das Akronym oft als "Looah" aus. Es ist nichts Besonderes, nicht einmal etwas wirklich Neues. LUA bezieht sich auf die Praxis der Verwendung von Benutzerkonten ohne Berechtigungen, sowohl für interaktive Benutzer als auch für Dienste.

Das Longhorn-Team möchte die Sicherheit vereinfachen. Sie sind der Ansicht, dass es zwei Ebenen des Zugriffs auf das System geben sollte: die geringsten Berechtigungen und die Verwaltung. Sie haben sogar die Gruppe "Power Users" (in einigen Kreisen als "admin-lite" bezeichnet) in Longhorn als veraltet markiert.

Da die Gruppe "Power Users" weg ist, müssen Anwendungsentwickler wirklich eine Wahl treffen. Sie müssen entscheiden, welche der beiden Berechtigungsstufen (LUA oder administratorisch) ihre Anwendung für Longhorn benötigt. Wenn die Anwendung keine Administratorrechte benötigt, sollte sie sorgfältig geschrieben werden, um unter einem Konto mit den geringsten Rechten zu funktionieren. Das bedeutet, dass tests (und, wie man hofft, sogar den Code schreiben) mit normalen Benutzerkonten. Beispielsweise sollte eine LUA-Anwendung Datendateien an einem sicheren Ort schreiben, z. B. im Benutzerprofil, im Gegensatz zur Verzeichnisstruktur "Programme". Aber was geschieht mit Anwendungen, die nicht für Longhorn umgeschrieben werden? Was geschieht, wenn diese Anwendungen auch unter Windows XP nicht gut unter Konten mit den geringsten Rechten ausgeführt werden? Ein Longhorn-Feature namens Application Impact Management (AIM) kann diese Apps möglicherweise trotzdem unter LUA ausführen, wie Sie in Kürze sehen werden.

Die (veraltete) Gruppe "Power Users"

Wenn Sie an ein Administratorkonto mit "hohem" Zugriff und ein normales Benutzerkonto mit "geringem" Zugriff denken, kann ein Power User-Konto als "mittlerer" Zugriff bezeichnet werden. Die Gruppe "Hauptbenutzer" darf Teile des Dateisystems und der Registrierung lesen und schreiben, die normalerweise nicht für Konten mit geringsten Rechten gelten (d. a. normale Benutzerkonten, die keine Mitgliedschaft in privilegierten Gruppen wie Administratoren oder Hauptbenutzern besitzen). Viele Benutzer, die versuchten, als normale Benutzer auszuführen, stellten fest, dass so viele Softwarefehler aufgetreten sind, dass sie beschlossen, ihre Konten der Gruppe "Power Users" hinzuzufügen, wodurch fast alle Probleme behoben wurden, die sie hatten. Aber sie wurden nicht mehr wirklich mit den geringsten Rechten ausgeführt. Unter Windows XP kann beispielsweise jede Schadsoftware, die mit dieser "mittleren" Berechtigungsstufe ausgeführt wird, andere Anwendungen kompromittieren, die im Verzeichnis "Programme" gespeichert sind, vertrauenswürdige COM-Komponenten durch Trojaner ersetzen usw. Wenn der Benutzer das nächste Mal unter ihrem Administratorkonto auf einem so kompromittierten Computer ausgeführt wird, können Sie sicher sein, dass die Schadsoftware auch über einen zuvor installierten Trojaner ausgeführt wird. Daher erhalten Sie keinen wirklichen Schutz, der als Power User ausgeführt wird.

AIM: Application Impact Management

Das Longhorn-Team ist der Ansicht, dass es wichtig ist, mit den geringsten Privilegien zu laufen. Sie möchten, dass dieser Begrüßungsbildschirm eine Liste von Benutzerkonten enthält, die hauptsächlich aus Konten mit den geringsten Rechten bestehen. Aber sie haben auch ihre Füße in der Realität geerdet. So wie viele große Software heute das Windows Logo-Programm vollständig ignoriert, kann auch die LUA-Initiative von großer Software im Longhorn-Zeitrahmen ignoriert werden. Uninformierte Anwendungsentwickler schreiben weiterhin Software, die Datendateien aus der Verzeichnisstruktur "Programme" liest und schreibt. Sie schreiben auch weiterhin Registrierungsdaten in HKEY_LOCAL_MACHINE anstelle von HKEY_CURRENT_USER. Ersteres ist für das Schreiben von normalen Benutzern nicht zulässig, sodass letzteres für das Speichern von Anwendungseinstellungen vorzuziehen ist, wenn die Registrierung überhaupt verwendet werden muss.

Wenn Windows XP erkennen kann, dass eine Anwendung mehr Berechtigungen benötigt (dies ist selten, tritt aber gelegentlich bei Setupprogrammen auf), informiert es den nicht privilegierten Benutzer darüber, dass die Anwendung Administratorrechte für die Ausführung benötigt, und öffnet bequem ein Dialogfeld zum Erfassen des Benutzernamens und des Kennworts eines Administratorkontos. Das Programm wird dann unter dem angegebenen Konto ausgeführt. Dies funktioniert jedoch nicht immer, da viele Anwendungen nicht für die Installation unter einem Konto geschrieben und unter einem anderen verwendet werden.

Longhorn verfolgt einen völlig anderen Ansatz. Anstatt den Benutzer zu ermuntern, Rechte zu erhöhen, damit die Anwendung ordnungsgemäß funktionieren kann, bevorzugt Longhorn die Ausführung der Anwendung unter LUA. Aber was geschieht, wenn die Anwendung versucht, in HKEY_LOCAL_MACHINE oder in die Verzeichnisstruktur "Programme" zu schreiben? Longhorn gibt der Anwendung mithilfe einer Strategie zum Kopieren beim Schreiben eine eigene virtualisierte Ansicht der Ressource, die sie ändern möchte. Wenn die Anwendung versucht, in eine Datei im Verzeichnis "Programme" zu schreiben, gibt Longhorn der Anwendung eine eigene private Kopie der Datei, und sie kann eingeschaltet werden. Auf diese Weise kann jede Schadsoftware, die in einem AIM-Szenario losgeht, versuchen, eine häufig verwendete ausführbare Datei unter der Verzeichnisstruktur "Programme" zu überschreiben, vielleicht WINWORD.EXE. Aber was am Ende überschrieben wird, ist eine private Kopie, die nur die Schadsoftware sehen kann. Die Version von WINWORD.EXE dem Benutzer angezeigt wird, ist weiterhin die ursprüngliche, nicht beschädigte Version.

Verlassen Sie sich nicht auf AIM, um Sie zu retten. Schreiben Sie Ihre Anwendung so, dass sie vom ersten Tag an unter LUA ausgeführt wird.

PA: Geschützter Administrator

Selbst wenn jede Anwendung im Longhorn-Zeitrahmen für die Ausführung unter LUA behoben werden sollte, gibt es weiterhin Anwendungen, die wirklich Administratorrechte erfordern. Sie umfassen Hilfsprogramme wie Sicherungssoftware, Festplattendefragmentierung und Neupartitionierungssoftware, Unternehmensverwaltungssoftware, und die Liste geht weiter. Der Benutzer muss also irgendwann ein Administratorkonto verwenden, um bestimmte Aufgaben zu erledigen. Und seien wir ehrlich, viele Leute werden den Rat ignorieren, LUA-Konten zu erstellen und einfach die ganze Zeit als Administratoren auszuführen.

Das Longhorn-Team hat ein übersichtliches Schema entwickelt, um Sie zu schützen, wenn Sie unter einem Administratorkonto ausgeführt werden. Es handelt sich um ein Feature namens Geschützter Administrator, und wenn es aktiviert ist, können Sie immer unter einem Administratorkonto ausgeführt werden und sich einigermaßen sicher fühlen, da die überwiegende Mehrheit der von Ihnen ausgeführten Anwendungen mit einem speziellen eingeschränkten Token ausgeführt wird, einem Token, das dem in einem LUA-Szenario ähnelt. Nur eine Anwendung, die Sie "segnen" oder die Ihr Unternehmen bereitgestellt und als vertrauenswürdig eingestuft hat, wird mit Ihrem vollständigen Verwaltungstoken ausgeführt. Eine Möglichkeit, eine Anwendung als vertrauenswürdig festzulegen, besteht darin, ihr Bereitstellungsmanifest zu signieren. Warum ist dies nützlich? Ich möchte Ihnen ein Beispiel geben.

Ein Benutzer, der normalerweise als Administrator ausgeführt wird, öffnet ihren Longhorn-E-Mail-Client und beginnt mit dem Durchsuchen von E-Mails. Sie stößt auf eine E-Mail, die von jemandem stammt, den sie kennt, und öffnet eine Anlage. Sie weiß nicht, dass ihr Freund kürzlich von einem E-Mail-Wurm infiziert wurde, und diese Nachricht enthält Schadsoftware. Wenn die Schadsoftware ausgeführt wird, stellt sie fest, dass sie sehr wenig Berechtigungen auf dem System hat. In der Verzeichnisstruktur "Programme" kann nichts geändert werden. Com-Objektregistrierungen unter HKEY_LOCAL_MACHINE können nicht geändert werden. Dies soll nicht heißen, dass es nichts Schlechtes tun kann, aber die Situation ist viel besser, als es gewesen wäre, wenn die Schadsoftware mit Administratorrechten ausgeführt wurde.

Aber warte, habe ich nicht gesagt, dass der Benutzer als Administrator ausgeführt hat, als er die E-Mail-Anwendung ausgeführt hat? Ja, das war tatsächlich der Fall. Die E-Mail-Anwendung wurde jedoch nicht als "gesegnete" Administrator-App bezeichnet. tatsächlich wurde es als LUA-Anwendung geschrieben. So erhielt es ein eingeschränktes Token, und die Schadsoftware als Folge. Dies ist der ganze Punkt der geringsten Rechte. Wenn Sie die Kontrolle über das System verlieren (vielleicht, weil Sie versehentlich eine bösartige Software ausgeführt haben, oder vielleicht, weil Sie gerade auf den falschen Menüeintrag geklickt haben), wird der Schaden eingeschränkt oder möglicherweise vollständig verhindert.

Einige sicherheitsbewusste Administratoren implementieren diese Richtlinie bereits heute. Ich bin einer von ihnen. Ich habe zwei Konten, ein normales und ein administratives. Ich melde mich als normaler Benutzer an und wechsele gelegentlich zu meinem Administratorkonto, wenn ich mein System auf irgendeine Weise verwalten muss, damit instance auf meinem Computer ein virtuelles Verzeichnis hinzufügen, eine Datenbank in Microsoft SQL™ Server erstellen usw. (Falls Sie sich gefragt haben, verbringe ich etwa 95 Prozent meiner Zeit damit, als normaler Benutzer zu laufen, selbst wenn ich Software entwickelt habe.) Das Longhorn-Team hat diesen Ansatz formalisiert, eine Idee, die häufig als "Rechte zur richtigen Zeit" im Feature "Geschützter Administrator" (PA) bezeichnet wird. Das bedeutet, dass ich immer nur als Administrator ausführen kann, aber trotzdem mit den geringsten Rechten ausgeführt werden kann. Kein Hin- und Herwechsel mehr, Jonglieren mit zwei Benutzerprofilen usw.

Wenn dies nach einer ordentlichen Idee klingt und Sie dazu beitragen möchten, dass Benutzer dieses Feature tatsächlich verwenden können, müssen Sie sich ernsthaft mit dem Schreiben von Anwendungen kümmern, die mit den geringsten Rechten ausgeführt werden. Denn wenn dieses Feature aktiviert ist, wird eine Anwendung, die mehr Berechtigungen benötigt, als sie wirklich benötigt, unnötig unterbrochen, selbst wenn sie von einem Administrator ausgeführt wird, es sei denn, sie wurde als vertrauenswürdige Administratoranwendung festgelegt. Natürlich kann AIM Ihnen zu Hilfe kommen, aber Sie sollten sich nicht darauf verlassen, da Microsoft schätzt, dass 20 Prozent der Anwendungen wahrscheinlich nicht über AIM LUA-kompatibel gemacht werden können. Wenn Sie auf diese 20 Prozent fallen, kann Ihre Anwendung nicht ausgeführt werden. Wenn dies genug geschieht, wird niemand das Feature Geschützte Admin verwenden, und das wäre in der Tat eine sehr traurige Sache.

Weitere Vorteile ergeben sich, wenn mehr Anwendungen geschrieben werden, die mit den geringsten Berechtigungen ausgeführt werden. Beispielsweise können Unternehmen endlich ihre Arbeitsstationen sperren, sodass Mitarbeiter Konten mit den geringsten Rechten ausführen können. Dies vereinfacht die Verwaltung erheblich und senkt die Kosten. Jetzt ist es mehr denn je wichtig, Anwendungen zu schreiben, die mit den geringsten Berechtigungen ausgeführt werden. Sie können auf dieser Plattform einen Unterschied machen.

Verwaltete Anwendungen auf Longhorn

Eine der Meldungen aus PDC 2003 war, dass verwaltete Anwendungen die Zukunft sind. Durch das Schreiben von verwaltetem Code können Sie die neueste Revolution der Sicherheit auf der Windows-Plattform nutzen: Sicherheit über Codeidentität. Das von der Common Language Runtime (CLR) bereitgestellte beweisbasierte Sicherheitssystem, das häufig als CAS- oder Codezugriffssicherheit bezeichnet wird, ermöglicht es der CLR, zusätzliche Einschränkungen für Code zu platzieren, je nachdem, woher er stammt, wer ihn signiert hat usw. Diese zusätzliche Dimension der Sicherheit eröffnet neue Wege für die Softwareverteilung. Durch ausführen von Code in einer sicheren Sandbox können Clients jetzt sicher Code ausführen, der von einem zentralen Server heruntergeladen wurde, wodurch Features wie "keine Berührung" und "Einmal klicken" bereitstellung möglich sind, was die Verwaltungskosten weiter senkt. Und wer würde nicht eine echte Windows-Anwendung, die auf ihrem Computer ausgeführt wird, einer browserbasierten Anwendung vorziehen, wenn die Bereitstellungs- und Sicherheitsrisiken ähnlich wären?

In Longhorn kann jede verwaltete Anwendung die spezifischen Berechtigungen angeben, die sie benötigt, um über das Anwendungsmanifest zu funktionieren. Codelist 1 zeigt ein Beispielmanifest, das beim Erstellen eines vom Assistenten generierten Standardprojekts "Longhorn Application" generiert wurde. Beachten Sie den Abschnitt TrustInfo und den darin enthaltenen Berechtigungssatz. Dies sind die Berechtigungen, die die Anwendung zum Ausführen benötigt.

Codeauflistung 1. Ein Anwendungsmanifest

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

Eine LUA-kompatible verwaltete Anwendung enthält immer einen Abschnitt wie diesen, und der Vertrauensverwalter in Longhorn verwendet diese Informationen, um zu bestimmen, ob die Anwendung auf dem Computer installiert werden kann. Wenn die Anwendung sorgfältig codiert ist, kann sie möglicherweise mit so geringen Berechtigungen ausgeführt werden, dass der Vertrauensverwalter ihr die Bewertung "kein Risiko" zuweisen kann und die Anwendung sofort installiert und ohne Benutzereingriff ausgeführt werden kann. Wenn die Anwendung jedoch eine gefährlichere Risikobewertung basierend auf den von ihr angeforderten Berechtigungen bewertet, wird der Benutzer mit einem Dialog aufgefordert, der die potenziellen Gefahren beschreibt, die von der Anwendung ausgehen. Der Benutzer kann dann auswählen, ob die Anwendung installiert und ausgeführt werden soll.

Die Angabe Ihrer Absichten im Manifest im Voraus ist eine gute Idee, denn wenn Sie dies nicht getan haben, kann der Vertrauensverwalter nur das Schlechteste über Ihre Anwendung annehmen, und die dem Benutzer zum Ausdruck gebrachte Risikobewertung wird umso düsterer erscheinen. Daher ist es eine wirklich gute Idee, die erforderlichen Berechtigungen in Ihrem Manifest auszudrücken. Überspringen Sie diesen Schritt nicht.

In einer Studie, die auf der PDC 2003 erwähnt wurde, fand Microsoft heraus, dass 40 Prozent der Benutzer immer auf "Nein" klicken, wenn Sicherheitsdialoge wie ActiveX-Steuerelement-Downloadwarnungen angezeigt werden. Es ist klar: Wenn Sie Ihre Software über das Internet an Benutzer verteilen möchten, hoffen Sie vom Vertrauensmanager in Longhorn auf eine Risikobewertung von "kein Risiko", sodass der Benutzer vor der Installation und Ausführung Ihrer Anwendung nicht aufgefordert wird. Sie fragen sich also möglicherweise, ob es einen dokumentierten Satz von Berechtigungen gibt, die immer als "kein Risiko" bewertet werden. Es stellt sich heraus, dass es eine solche Definition gibt, die als SEE-Berechtigungssatz bezeichnet wird.

Der Berechtigungssatz "Kein Risiko"

Sie haben vielleicht gehört, dass dies bei PDC 2003 als SEE (Secure Execution Environment) bezeichnet wird, aber die meisten Leute finden diesen Begriff ziemlich verwirrend, daher nenne ich dies einfach den Berechtigungssatz ohne Risiko. Longhorn wird mit einem speziellen Berechtigungssatz ausgeliefert, der immer mit dem Standardvertrauens-Manager in Longhorn als "kein Risiko" bewertet. Wenn Sie eine Anwendung schreiben, deren Berechtigungsanforderungen vollständig in den Berechtigungssatz ohne Risiko fallen, kann sie installiert und ausgeführt werden, ohne dass überhaupt Vertrauenswarnungen angezeigt werden. Code, dem Berechtigungen nur innerhalb dieser Gruppe gewährt werden (zumindest so, wie er ursprünglich von Microsoft definiert wurde), sollte nicht in der Lage sein, Ihren Computer absichtlich oder versehentlich zu beschädigen.

Wenn Sie also möchten, dass Ihre Anwendung installiert und ausgeführt wird, ohne dass der Benutzer mit einem beängstigenden Dialogfeld aufgefordert wird, sollten Sie sich auf Aktivitäten beschränken, die durch diesen Berechtigungssatz zulässig sind. Sie sollten wissen, dass das Longhorn-Team erwägt, diesen Berechtigungssatz von Administratoren konfigurierbar zu machen, sodass das, was an einem Standort als "kein Risiko" betrachtet wird, an einer anderen Seite anders sein kann. Für die überwiegende Mehrheit der Longhorn-Installationen ist der Berechtigungssatz ohne Risiko jedoch der Standard, der mit dem Betriebssystem ausgeliefert wird.

Wie sieht es aus? Sehen Sie sich das Manifest in Codelist 1 noch einmal an. Notieren Sie sich die ID, die dem im Abschnitt "TrustInfo" "SeeDefinition" definierten PermissionSet zugewiesen wurde.

So sieht der Berechtigungssatz ohne Risiko für den PDC 2003-Vorschaubuild aus: Mit der uneingeschränkten DateiDialogPermission können Sie Dateien der Wahl des Benutzers über die Standardklassen OpenFileDialog und SaveFileDialog lesen oder schreiben, aber Sie dürfen nichts über die Struktur des Dateisystems des Benutzers erfahren, einschließlich des Namens der vom Benutzer ausgewählten Datei. Mit IsolatedStoragePermission kann eine Assembly bis zu 5 MB benutzerspezifischen Zustand auf der Festplatte des Benutzers lesen und schreiben, ohne sie dazu auffordern zu müssen, ein Dateidialogfeld einzugeben. Mit SecurityPermission kann Ihr Code überhaupt ausgeführt werden. Die UIPermission ermöglicht Es Ihnen, auf dem Bildschirm zu zeichnen, jedoch nur in Ihren eigenen Fenstern, und gewährt Ihnen eingeschränkten Zugriff auf die Zwischenablage (Sie können den Inhalt nicht programmgesteuert lesen, aber der Benutzer kann aus der Zwischenablage in Ihre Steuerelemente einfügen). PrintingPermission ermöglicht Das Drucken, aber nur, wenn Sie dies über das Druckdialogfeld tun. Ihr Code kann Druckaufträge nicht im Hintergrund starten, ohne dass der Benutzer weiß, dass Sie dies tun. Die "Avalon"-spezifische Berechtigung ermöglicht Ihrem Code das Erstellen von Vollbildfenstern, solange sie über einen Rahmen verfügen, der vom Betriebssystem gesteuert wird (So können Sie z. B. den Anmeldebildschirm nicht vorsingen).

Denken Sie daran, dass sich diese Definition im Laufe der Zeit mit ziemlicher Sicherheit ändern wird. es kann sich sogar ändern, bevor die Longhorn Beta ausgeliefert wird. Nehmen Sie also meine Beschreibung hier mit einem Körnchen Salz. Hoffentlich wird dieser Artikel Sie dazu motivieren, einige der Features mit den geringsten Rechten in der .NET Framework zu untersuchen, z. B. isolierter Speicher und allgemeine Dialoge, da die endgültige Definition des Berechtigungssatzes ohne Risiko sehr wahrscheinlich erfordert, dass Sie diese Features verwenden müssen, um einen Vertrauensdialog zu vermeiden.

Das Definieren eines Berechtigungssatzes ohne Risiko ist keine triviale Aufgabe. Das Longhorn-Team weiß, dass bei einer zu restriktiven Definition nicht genügend Anwendungen in der Lage sein werden, sie zu verwenden. Aber wenn es zu freizügige ist, wird Malware es definitiv missbrauchen. Man hofft, dass das Team den Sweet Spot findet. Abbildung 1 ist ein Diagramm, das den Berechtigungsbereich für Longhorn-Anwendungen zeigt, von einer gesegneten Administratoranwendung bis hin zu Anwendungen, die für die Ausführung mit dem SEE-Berechtigungssatz konzipiert sind.

Abbildung 1. Anwendungsarten

Tools

Das Erstellen von Anwendungen mit den geringsten Rechten war nie trivial. Sie benötigen Richtlinien und Tools, die Ihnen helfen können. Wir haben einige Beispiele für diese Tools auf PDC 2003 gesehen. Die erste davon ist Visual Studio® 2005 (Codename "Whidbey" im PDC 2003-Zeitrahmen).

Diese neue Entwicklungsumgebung bietet eine Reihe von Features, die das Ziel einer Umgebung mit den geringsten Rechten erleichtern. Sie können beispielsweise einen Berechtigungssatz auswählen, den Sie beim Debuggen Ihrer Anwendung erzwungen haben möchten. Ein guter Ausgangspunkt für Longhorn-Anwendungen wäre der SEE-Berechtigungssatz. Für vorhandene Anwendungen empfiehlt es sich am besten, den Internetberechtigungssatz als Ziel festzulegen, was ziemlich nahe an der heutigen Definition des SEE liegt.

Sobald Sie mit dem Debuggen mit reduzierten Berechtigungen beginnen, werden Sie sicher auf einige unerwartete SecurityExceptions stoßen. Abbildung 2 zeigt ein klassisches Beispiel, in dem der Entwickler ein Dateidialogfeld verwendet, um den Benutzer zur Eingabe eines Dateinamens aufzufordern und dann versucht, den angegebenen Dateinamen zu lesen. Wenn Ihnen FileDialogPermission gewährt wird (wie sie sich im BERECHTIGUNGSsatz SEE befinden), können Sie den Benutzer zur Eingabe einer Datei auffordern. Es ist Ihnen jedoch ausdrücklich nicht gestattet, den vom Benutzer ausgewählten Dateinamen anzuzeigen. Stattdessen müssen Sie eine Methode (OpenFile) aufrufen, um einen Stream zu öffnen, den Sie dann zum Lesen aus der Datei verwenden können. Visual Studio 2005 bietet Empfehlungen, die entwicklern helfen, die richtige Methode für die Verwendung der OpenFileDialog-Klasse zu finden, um die Sicherheitsausnahmeregelung zu vermeiden.

Abbildung 2. Bessere Toolunterstützung

Ein weiteres nützliches Tool, das auf der PDC 2003 angekündigt wurde, heißt PermCalc. Dies ist ein Befehlszeilentool, das eine Assembly auswertet und über die Heuristik bestimmt, welche Berechtigungen sie zum Ausführen benötigt. Dieses Feature ist auch für die Aufnahme in Visual Studio 2005 geplant. Dies ist eine hervorragende Möglichkeit, Umgebungen mit den geringsten Rechten als Ziel zu verwenden. Ein ähnliches Tool, das es heute gibt, heißt Windows Application Verifier, Teil des Windows Application Compatibility Toolkit. Dieses Tool kann Ihnen helfen, zu erkennen, wann Ihre Anwendung gegen Regeln verstößt, z. B. das Schreiben in geschützte Teile des Dateisystems oder der Registrierung.

Zusammenfassung

Longhorn verspricht, eine hervorragende Plattform für Anwendungen mit den geringsten Rechten zu sein. Beginnen Sie noch heute, indem Sie zunächst verwalteten Code schreiben. Stellen Sie beim Erstellen von Desktopanwendungen luakonform (und verwenden Sie die Windows-Anwendungsüberprüfung, um Ihre Arbeit zu überprüfen). Wenn möglich, sollten Sie die für den Moment festgelegte Internetberechtigung festlegen, und Sie werden wahrscheinlich direkt in die SEE-Eigenschaft passen, wenn Longhorn ausgeliefert wird.

Weitere Informationen

Lesen Sie Brent Rectors Buch Einführung "Longhorn" für Entwickler.

Über den Autor

Keith Brown ist ein unabhängiger Berater, der sich auf Anwendungssicherheit spezialisiert hat. Er verfasste das Buch Programming Windows-Sicherheit (Addison-Wesley, 2000) und schreibt ein neues Sicherheitsbuch für .NET-Programmierer. Lesen Sie das neue Buch online unter http://www.develop.com/kbrown.