Windows oder Linux: Welches Betriebssystem ist sicherer?

Der Erfolg von Windows NT hing entscheidend davon ab, dass möglichst viele Windows-3.1-Anwendungen auf Windows NT liefen. Diese kannten keine Security. Sie gingen davon aus, dass Schreibrechte in jedem Verzeichnis vorliegen. Ferner riefen sie jede Systemfunktion einfach auf, ohne vorher ein Recht dafür anzufordern.

Das Ergebnis ist, dass man sich einen Benutzeraccount einrichten muss, der Administratorrechte besitzt, die alle aktiviert sind. Andernfalls lassen sich die Anwendungen weder installieren noch betreiben. So wird das System der abgestuften Rechte wirkungslos. Zwar braucht nicht jedes Programm alle Rechte, da aber nicht vorhersehbar ist, welche Programme der Benutzer gleichzeitig startet, existiert faktisch die gleiche „Alles-oder-nichts-Situation“ wie unter Unix.

Daran änderte sich auch nichts, als mehr und mehr 32-Bit-Windows-Applikationen erschienen. Im Endeffekt blieb es bis heute so, dass man unter einem Administrator-Account arbeiten muss. Neu ist lediglich die Benutzerkontensteuerung von Vista, die viele Funktionen erst nach einer Bestätigung oder Passwort-Eingabe freischaltet. Je nach Anwendung poppt sie allerdings mehr oder weniger oft beim ganz normalen Arbeiten auf, so dass sie viele Benutzer deaktivieren.

Windows 95 verantwortlich für viele Sicherheitsmängel

Microsoft schiebt heute gerne die Schuld auf die Entwickler von Anwendungsprogrammen, sie hätten lediglich ihre 16-Bit-Windows-Anwendungen eins zu eins in das 32-Bit-Speichermodell portiert und die gegenüber Unix fortschrittlichen Sicherheitsmechanismen nicht genutzt.

Dabei scheint Microsoft offensichtlich verdrängt zu haben, dass es von 1995 bis 2000 zweigleisig gefahren war und neben Windows NT auch das MS-DOS-basierte Windows auf das 32-Bit-API aufgebohrt hat. Damals bewarb Microsoft das 32-Bit-API mit dem Mehrwert, dass 32-Bit-Windows-Anwendungen sowohl auf Windows 95 als auch auf Windows NT laufen. Allerdings beherrschten die Windows-Versionen 95, 98 und Millennium keinerlei Security.

Um die Anwendungen so zu gestalten, dass sie auf beiden Windows-Versionen laufen, mussten die Hersteller die Security außer Acht lassen. Viele Security-APIs existierten in den MS-DOS-basierten Windows-Versionen erst gar nicht. Bei anderen APIs mussten Entwickler für die sicherheitsrelevanten Parameter den Null-Pointer einsetzen. Unter Windows NT und Windows 2000 liefen die Programme nur, wenn sie unter einem Administrator-Account gestartet wurden.

Unix-Programmierer sind gezwungen an Security zu denken

Ganz anders ist das unter Unix. In den 80er Jahren konnten sich Unix-Anwender auf einem Großrechner nicht als root anmelden. Erst als Linux Mitte der 90er Jahre größere Popularität erlangte, verbreitete sich Unix auf Personal-Computern, bei denen der Benutzer gleichzeitig Computerbesitzer ist und das Root-Passwort kennt.

Unix-Entwickler schreiben Anwendungsprogramme in der Regel so, dass Root-Rechte weder für die Installation noch für die Ausführung erforderlich sind. Das Konzept ist einfach: Die Anwendungen können in allgemein zugänglichen Verzeichnissen, beispielweise /bin oder /usr/bin, installiert werden. Sie lassen sich jedoch auch in privaten Verzeichnissen einrichten, etwa /home/user/bin. Meist gibt es zwei Konfigurationsdateien, eine im Verzeichnis /etc, die der Superuser verwaltet, eine weitere im Home-Verzeichnis des Benutzers. Ist ein Parameter in beiden Dateien angegeben, so hat die des Benutzers Priorität.

Unter Windows ist eine ähnliche Vorgehensweise mit der Registry realisierbar. Sowohl MS-DOS-basierte Windows-Versionen als auch Windows-NT-basierte Versionen haben die beiden Registry-Äste HKEY_LOCAL_MACHINE und HKEY_CURRENT_USER. Desktop-Anwendungen könnten versuchen, Default-Werte in HKEY_LOCAL_MACHINE zu schreiben. Benutzereinstellungen kommen hingegen in HKEY_CURRENT_USER. Scheitert das Schreiben in HKEY_LOCAL_MACHINE mangels Berechtigungen, dann gibt es entweder keine Default-Werte oder die Anwendung fordert zur Eingabe von Administrator-Credentials auf.

Dieses einfache Prinzip verhindern allerdings die Microsoft-Logo-Programme. Um das begehrte Logo zu erhalten, müssen Programme unter anderem Uninstall-Information in HKEY_LOCAL_MACHINE schreiben. Das bedeutet im Klartext: Ohne Administratorrechte gibt es keine Logo-konforme Installation.