'Datensicherheit: Teil 7 - Lokal mit Windows'

Windows und Mehrbenutzerumgebungen

Sämtliche bisher genannten Tips der Datensicherheit-Serie sind höchstens halb so viel wert, wenn man unter Windows ständig mit Administrator-Rechten arbeitet. Als Beispiel: Es kann nicht angehen daß man ständig erpicht darauf ist, so wenig Spuren wie möglich im Internet zu hinterlassen bloß um dann im nächsten Moment wegen einer Browsersicherheitslücke einem Trojaner mit den Admin-Rechten Tür und Tor im System zu öffnen auf daß fortan alle Paßwörter mitgeloggt werden. Das wäre nicht nur inkonsequent sondern würde auch den Aufwand aller vorherigen Maßnahmen für umsonst erklären.

Grundsätzlich gilt die Anleitung für _Windows XP Professional_, sollte aber mit eventuellen Einschränkungen auch unter _Home_ funktionieren. Mit Vista habe ich kaum Erfahrung gesammelt, aber grundsätzlich sollte es dort auch so funktionieren. Es gilt: Auf eigene Gefahr zu handeln!

Man loggt sich (noch) als Administrator ein und startet die Computerverwaltung _compmgmt.msc_. Bei den Benutzern sollte nun das Konto "Administrator" und das Eigene zu sehen sein (neben weiteren Systemeigenen). Da in der Wiederherstellungskonsole von Windows das Konto "Administrator" zum einloggen benutzt wird habe ich mir einen zusätzlichen Account namens "root" angelegt. Das ist einfach nur als zusätzliche Maßnahme gedacht, damit "Administrator" unangetastet bleibt. "root" wird in die Gruppe "Administratoren" gesteckt und der eigene Benutzer bekommt als Zuweisung nur die Gruppe "Benutzer", "Hauptbenutzer" haben Schreibrechte im Programme-Ordner, das kann schlecht sein.

Hiermit wäre auch schon fast die Hauptarbeit getan, einzig noch einmal neu einloggen muß man sich damit jeder Teil von Windows kapiert hat daß man nicht mehr Administrator ist.

Das wars! So Schnell ging es, aber andere Probleme fangen jetzt richtig an. Dadurch daß nun Schreibrechte auf \Programme, \Windows und diverse zur Installation von Programmen wichtige Teile der Regedit verweigert werden, benötigt man Zusatztools.

Grundsätzlich empfehle ich da wieder die "Sysinternals". Dabei sind _filemon_ (Filemonitor) und _regmon_ (Registrymonitor) womit sich bei wortlos sich selber beendenden Programmen eventuell feststellen läßt worauf nicht zugegriffen werden konnte. Aber auch procexp (Processexplorer) der alle Prozesse und Child-Prozesse als Baum darstellt ist praktisch. Die Baumanordnung der Child-Prozesse ist wichtig, da auch Rechte vererbt werden, dies macht sich der nächste Softwaretip zunutze:

Machmichadmin.cmd ist ein Skript von der c't. Zum erklären muß ich ein wenig ausholen; manche Setupsoftware ist schlichtweg schlecht geschrieben, so daß wenn man sich als Administrator eine Software installiert, dann dem Nichtadministrator wichtige Einstellungen oder einfach nur Verknüpfungen im Startmenü fehlen. Weil dies ärgerlich ist, aber das Setup mit Admin-Rechten ausgeführt werden muß, wird das Prinzip der Rechtevererbung benutzt.

> > > 1. Machmichadmin.cmd wird von einem Nichtadmin gestartet > > 2. Nun muß das Paßwort für den (in der machmichadmin.cmd von Hand eingetragenen) Administrator-Account eingegeben werden > > 3. Machmichadmin.cmd ruft sich selber nun in diesem Adminaccount auf und > > 4. steckt den Nichtadmin für den Bruchteil einer Sekunde in die Gruppe "Administratoren". Zugegeben eine Sicherheitslücke, aber eine kleine im Vergleich zur ständigen Arbeit als Admin. > > 5. Nun muß (nur einmal) das Paßwort des Nichtadmin eingegeben werden > > 6. Die Zweite Machmichadmin-Shell mit den Admin-Rechten startet sich nun ein drittes mal, diesmal wieder unter dem (normalerweise) Nicht-Adminaccount. Da der normale Benutzer zuvor in die Administratoren-Gruppe aufgenommen wurde erhält auch die Shell Admin-Rechte. > > 7. Der Benutzer wird wieder aus der Gruppe der Administratoren herausgeschmissen. >

Das klang jetzt vielleicht total kompliziert, ist aber eigentlich ganz easy. Der Vorteil ist nun daß man jetzt eine Shell offen hat die *1. *unter dem eigenen Benutzernamen läuft und *2. *Admin-Rechte hat. Neben allen üblichen Kommandozeilenbefehlen kann man auch schlichtweg Verknüpfungen per Drag&Drop hierrauf fallen lassen, nach Bestätigung mit Enter starten diese Programme dann mit Admin-Rechten.

Windows hat nun allerdings 3 Bugs diesbezüglich:

  1. Wer eine Explorer.exe in der Admin-Shell startet kann dann keine Explorer-Fenster mehr als normaler Benutzer öffnen.

  2. Der Admin-Explorertask bleibt manchmal nach Schließen des Fenster im Speicher hängen.

  3. Die Admin-Explorerfenster aktualisieren sich nicht automatisch, hier muß mit _F5_ nachgeholfen werden.

Mir war das zu doof, deswegen verwende ich in der Admin-Shell grundsätzlich einen anderen Dateimanager als den Hauseigenen. Bei mir ist es "Speed Project", das war in der Version 9 auf einer c't als Vollversion dabei und entspricht einem "Norton Commander"-Klon. Sehr gut bei S.P. ist, daß es die Systemsteuerung in einem Menü anzeigt und sich somit die einzelnen Elemente mit Adminrechten starten lassen. Über das Startmenü funktioniert kein Drag&Drop mit den Systemsteuerungselementen.

Nun gibt es Software die ihre Daten nicht nach %userprofile%\Anwendungsdaten abspeichern. Winamp zählt z.B. auch dazu, alleine schon wegen der Playlist. Hierbei ist zu überlegen für kleine Programme einen Ordner mit Schreibrechten für die Gruppe "Benutzer" anzulegen und die Software dorthin zu installieren - eventuell schadet auch ein Schreibzugriff für die "Benutzer"-Gruppe auf Programme\Winamp nicht - das muß dann jeder selber abwägen.

Noch etwas aus eigener Erfahrung; das Installieren über die Machmichadmin.cmd funktioniert bei mir in ca. 95% aller Fälle, für ganz hartnäckige Fälle halt als "root" einloggen. Mit der "Schnellen Benutzerumschaltung" von Windows auch nicht der Zeitaufwand...