UAC-konforme Anwendungen entwickeln Die Benutzerkontensteuerung wird von einigen Anwendern und Entwicklern verflucht. Dieser Workshop zeigt, wie eigene Anwendungen abgestimmt werden müssen, damit diese unter Windows Vista und Windows 7 korrekt arbeiten.
Autor:  Ralf Ehlert	Bewertung:     [ Jetzt bewerten ]	Views:  34.729

Geben Sie hier Ihre persönliche Bewertung ab! Anzahl Bewertungen bisher: 12 Bewertung insgesamt: sehr gut Durchschnittliche Bewertung: 4.5 von 5 Sternen

sehr gut     gut     nützlich     mittelmäßig     mangelhaft

Die Benutzerkontensteuerung von Windows Vista und 7 meistern

Der Sinn von Benutzerrechten

Benutzergruppen als Sicherheitsfeature
Sicherheit ist ein wichtiges Thema und Windows bietet zahlreiche Funktionen, dieser Anforderung gerecht zu werden.

Welche Aktionen ein Benutzer ausführen darf regeln die Benutzerrechte. Diese können einem individuellem Benutzer zugewiesen werden oder einer ganzen Benutzergruppe.

Mit der Installation von Windows werden einige Standardbenutzergruppen eingerichtet. Zwei davon sind besonders wichtig: Administrator und Benutzer.

Ein Administrator ist mit sehr weitreichenden Rechten ausgestattet und darf nahezu alles am System. Seine Aufgabe ist es, das System zu verwalten und zu warten. Dazu gehört das Hinzufügen/Entfernen von Programmen, die Änderung von Systemeinstellungen oder neue Benutzer einrichten.

Benutzer hingegen haben bedeutend weniger Rechte. Sie haben lediglich Zugriff auf das eigene Benutzerprofil, aber nicht auf das komplette Dateisystem. Weiterhin können sie installierte Programme nutzen oder benutzerbezogene Systemeinstellungen ändern (z.B. Hintergrundbild des Desktops).

Anwendungen haben dieselben Berechtigungen wie der angemeldete Benutzer, der die Anwendung ausführt. Somit besitzen Schadprogramme unter einem administrativen Konto ein wesentlich höheres Schadenspotenzial als unter einem Standardkonto. Daher sind wir als Programmierer mit gefördert, aktiv bei der Sicherheit mitzuwirken, dass unsere Programme unter Standardrechte lauffähig sind.

Benutzerkontensteuerung - Warum?
Durch die historische Entwicklung von Windows bedingt arbeiten viele Benutzer mit administrativen Berechtigungen. Windows XP vereinigte die Produktlinien NT (Windows NT und 2000) und DOS (Windows 9x/Me). Letztere kennen keine Benutzerrechte - jeder Benutzer darf alles.

Benutzer arbeiten aus drei Gründen als Administrator:

• Es ist der Standardkontotyp bis Windows XP
• Es ist für einen Anwender schwer ersichtlich, wann eine Operation erhöhte Rechte benötigt
• Viele Programme erzwingen unnötigerweise Adminrechte

Das Schild-Symbol kennzeichnet ab Windows Vista Aufgaben, die höher privilegierte Berechtigungen benötigen. Dieses Symbol sollte auch in eigenen Anwendungen die Bereiche kennzeichnen, die weiterreichende Berechtigungen benötigen.

Ab Windows 2000 gibt es den Befehl „runas“, welcher es erlaubt, eine Anwendung unter einem anderen Benutzerkonto (Identität) auszuführen. Hierdurch wird ermöglicht, das Arbeiten mit administrativen Rechten auf die notwendigen Aufgaben zu minimieren und nicht generell als Administrator zu arbeiten.

Dieser Befehl hat aber den Nachteil, dass nicht jede Art von Anwendung so als Administrator ausgeführt werden kann. MSI-Pakete, welche dazu dienen, Software zu installieren und zu warten, unterstützen „runas“ nicht. Damit es doch klappt, muss ein Eingabeaufforderungsfenster mit administrativen Rechten gestartet werden und darüber das MSI-Paket ausgeführt werden. Für einen Standardanwender kein gangbarer Weg.

Die Benutzerkontensteuerung (UAC, User Account Control) erlaubt es mittels Knopfdruck bei Bedarf in einen administrativen Kontext für die Aufgabenausführung zu wechseln.

UAC im Detail
Welche Rechte ein Benutzer hat wird durch ein Security Token beschrieben. Dieses verwendet Windows um zu entscheiden, ob ein Ressourcenzugriff erfolgen darf oder nicht.

Ab Windows Vista besitzen Benutzer mit erweiterten Rechten (d.h. alle Rechte außerhalb der Benutzergruppe Benutzer) zwei Security Token: Eins mit allen Rechten und ein gefiltertes, welches vom Rechteumfang des eines Standardbenutzers entspricht.

Das erste Programm, welches bei der Benutzeranmeldung gestartet wird, ist der Windows Explorer. Damit werden die Windows-Startleiste und der Desktop angezeigt. Der Explorer wird mit dem gefilterten Security Token gestartet. Alle weiteren Programme erben standardmäßig dieses Token, womit diese ebenfalls nur Standardberechtigungen besitzen.

Ein Programm kann beim Starten auch erweiterte Benutzerrechte anfordern. Dies erfolgt über das Anwendungsmanifest. Werden diese erweiterten Benutzerrechte angefordert, erscheint der Bestätigungsdialog der UAC und der Benutzer muss dieser Heraufstufung zustimmen. Die Benutzerentscheidung wird nicht gespeichert, d.h. der Benutzer muss diese bei jeder Rechteerweiterung genehmigen.

Der Bestätigungsdialog wird hierbei auf dem s.g. Secure Desktop ausgeführt. Dieses ist isoliert und kann programmatisch nicht ferngesteuert werden. Erkennbar ist der Secure Desktop an dem abgedunkelten Desktophintergrund.

UAC-kompatible Anwendungen entwickeln

Wann werden Adminrechte benötigt?
Den wenigsten Aufwand hat man, wenn man erst gar keine erweiterten Rechte benötigt. Dies trifft für sehr viele Anwendungen zu und selbst für die Softwareentwicklung sind in vielen Fällen keine Adminrechte notwendig.

Leider geht es nicht immer als Standardbenutzer und es werden weiterreichende Berechtigungen benötigt. Nämlich dann, wenn systemweite Änderungen durchgeführt werden sollen.

Typische Aufgaben, die Adminrechte erzwingen (und in vielen Fällen vermeidbar sind):

• Schreiben ins Programme-Verzeichnis
• Direktes schreiben auf C: etc.
• Schreiben in HKLM

Diese Probleme lassen sich vermeiden, in dem man alternative Speicherorte verwendet. Diese lassen sich sehr bequem über System.Enviroment.GetFolderPath() auslesen. Die SpecialFolder-Enumeration definiert zahlreiche „besondere“ Orte. Sehr wichtig sind folgende:

• LocalApplicationData für benutzerspezifische Daten
• ApplicationData für benutzerspezifische Daten, welche im Roaming-Profil abgelegt werden
• CommonApplicationData für anwendungsspezifische Daten

Das Schreiben ins Programme Verzeichnis ist einer der häufigsten Ursachen, warum eine Anwendung unnötigerweise Adminrechte benötigt.

Damit bereits bei der Entwicklung auffällt, welche Aktionen weiterreichende Rechte benötigen, ist es sehr empfehlenswert, als Standardbenutzer zu entwickeln.

Aufgaben mit dem Schild-Symbol kennzeichnen
Aktionen, die erhöhte Rechte erfordern, sollen mit dem UAC-Schild-Symbol gekennzeichnet werden. Dafür wird ein eigenes Steuerelement entwickelt, um das wiederholte Setzen von Eigenschaften zu vermeiden.

Als erstes wird ein Klassenbibliotheksprojekt namens UacButton erstellt.

Bevor mit der Programmierung begonnen werden kann, müssen noch einige Vorbereitungen durchgeführt werden. Dazu werden die Projekteigenschaften durch einen Doppelklick auf My Project geöffnet. Unter Verweise werden Referenzen auf die .NET-Assemblies System.Drawing und System.Windows.Forms hinzugefügt.

Im Bereich Ressourcen wechselt man auf Bilder und fügt die Grafiken Shield16.png, Shield32.png und Shield48.png hinzu. Diese drei Dateien können hier als Zip-Archiv heruntergeladen werden. Weiterhin wählt man im Eigenschafsfenster unter Persistence die Option „Eingebettet in .resx“ aus. Alle bisherigen Änderungen sollten jetzt gespeichert werden.

Ersetzen Sie als nächstes den Code der Class1 durch nachfolgenden Code:

Option Strict On
 
Imports System.Drawing
Imports System.Windows.Forms
 
Public Class UacButton
  Inherits Button
 
End Class

Es werden zwei Namensräume eingebunden, die für die Erstellung von eigenen Steuerelementen benötigt werden. Weiterhin erbt unser UacButton von dem Standard-Button-Steuerelement.

Unser Button soll das UAC-Symbol links vor dem Buttontext darstellen. Dieses soll sich automatisch der Buttongröße anpassen. Dafür wird die Methode DisplayUacShield geschrieben:

Private Sub DisplayUacShield()
  If Me.Height > 55 AndAlso Me.Width > 55 Then
    Me.Image = My.Resources.Shield48
  ElseIf Me.Height > 39 AndAlso Me.Width > 39 Then
    Me.Image = My.Resources.Shield32
  Else
    Me.Image = My.Resources.Shield16
  End If
End Sub

Diese Methode werden wir im Konstruktor aufrufen sowie im Resize-Event, damit das Symbol passend dargestellt wird. Im Konstruktor werden noch einige Eigenschaften gesetzt, so dass die komplette Klasse wie folgt aussieht:

Option Strict On
 
Imports System.Drawing
Imports System.Windows.Forms
 
Public Class UacButton
  Inherits Button
 
  Public Sub New()
    ' Konstruktor der Basisklasse aufrufen
    MyBase.New()
 
    ' Eigenschaften setzen
    Me.ImageAlign = ContentAlignment.MiddleLeft
    Me.TextImageRelation = Windows.Forms.TextImageRelation.ImageBeforeText
    Me.Size = New Size(90, 23)
 
    ' UAC-Symbol anzeigen
    DisplayUacShield()
  End Sub
 
  Private Sub UacButton_Resize(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Resize
    DisplayUacShield()
  End Sub
 
  Private Sub DisplayUacShield()
    If Me.Height > 55 AndAlso Me.Width > 55 Then
      Me.Image = My.Resources.Shield48
    ElseIf Me.Height > 39 AndAlso Me.Width > 39 Then
      Me.Image = My.Resources.Shield32
    Else
      Me.Image = My.Resources.Shield16
    End If
  End Sub
End Class

Damit ist das Steuerelement fertig und kann verwendet werden:

Hinweis:
Bevor Sie das Steuerelement auf die Form platzieren können, müssen Sie die Anwendung zunächst einmalig starten und beenden. Anschließend steht Ihnen das neue Steuerelement ganz oben in der Toolbox zur Auswahl zur Verfügung.

Das Anwendungsmanifest konfigurieren

Anhand des Manifests können Anwendungen eine von drei verschiedenen Berechtigungsstufen anfordern, welche beim Starten des Prozesses ausgewertet werden. Diese können sehr einfach über Visual Studio konfiguriert werden, in dem man in den Projekteigenschaften auf die Schaltfläche „Einstellungen für die Benutzerkontensteuerung anzeigen“ klickt.

Das Manifest ist eine XML-Datei und durch die Kommentare wird ersichtlich, wie diese ggf. geändert werden muss. Die drei Levels sind:

• asInvoker: Anwendung läuft mit den Berechtigungen, wie der Prozess, der die Anwendung startet. Das ist i.d.R. der Windows Explorer, womit die Anwendung Standardberechtigungen erhält.
• highestAvailable: Die Anwendung erhält die maximalen Berechtigungen des Benutzers. Dies müssen nicht unbedingt Administratorrechte sein, da es auch weitere privilegierte Benutzergruppen gibt (z.B. Sicherungsoperator oder Domain-Administrator).
• requireAdministrator: Die Anwendung fordert Administratorrechte an.

Die eigene Anwendung sollte i.d.R. mit asInvoker lauffähig sein. Vereinzelte Aufgaben, die erhöhte Berechtigungen benötigen, werden in einen separaten Prozess ausgelagert, welche dann die höheren Berechtigungen anfordern über highestAvailable oder requireAdministrator.

Einen Prozess mit erhöhten Rechten starten
Das Starten eines Prozesses erfolgt durch die Klassen Process und ProcessStartInfo aus dem Namensraum System.Diagnostics:

Dim info As New ProcessStartInfo(processPath)
info.UseShellExecute = True
info.Verb = "runas"
Process.Start(info)

Wichtig ist es, dass die Eigenschaften UseShellExecute und Verb gesetzt werden, damit der UAC-Dialog erscheint:

Unter Windows XP erscheint übrigens folgender Dialog:

Sollte der Benutzer den Dialog mit Abbrechen schließen, wird eine Win32Exception ausgelöst, auf die reagiert werden kann.

Wirkt der Vista-Dialog nicht etwas abschreckend für einen normalen Anwender? Denn bei den Windows-Befehlen sieht der Dialog freundlicher aus:

Freundliche UAC-Dialoge für eigene Anwendungen
Welcher Dialog erscheint hängt davon ob, ob die eigene Anwendung digital signiert ist oder nicht. Dafür benötigt man zuerst ein Zertifikat für Codesignierung. Dieses kann entweder selbst erstellt (z.B. für interne Anwendungsbereiche) oder von einer bekannten CA (Certificate Authority - Zertifikatsherausgabestelle) wie VeriSign, Thawte oder Globalsign gekauft werden. Eine Anleitung zur Signierung findet sich auf  MSDN-Solve.