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.
Neueste Kommentare
7 Kommentare zu Windows oder Linux: Welches Betriebssystem ist sicherer?
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Was ist mit SELinux
Sowohl Redhat als auch SUSE kommen in den neusten Enterprise Versionen mit SELinux out of the box. SELinux schließt genau die angemängelten Buffer Overruns und damit einhergehender Priviledge escalation aus.
Was ist mit Opensolaris RBAC?
Damit kann ich in Unix mehr Granularität in die Rechte einführen.
Artikel gesponsort?
Der Artikel lobt ja Windows ziemlich. Gerade die Benutzersteuerung ist unter Windows schlechter, da eben keine Trennung erfolgt, wie der Artikel suggeriert. Erst mit Vista hat sich dies ein wenig verändert durch Einführung des UACs. Aber das auch gleich nervend. Während die superuser Funktion bei unixen eine Paßworteingabe erfordert muß man bei Vista 3 mal per Klick bestätigen (nicht 1 mal wie der Artikel behauptet). Dazu kommt dies bei Windows weitaus häufiger vor als bei unix basierenden System. bei letzteren kann der einfach Benutzer sogar neue Programme einspielen, halt nur in seine Account. Unter Vista muß immer der Admin her. Teilweise sogar beim ausführen von Programmen.
AW: Artikel gesponsort?
Hast recht, dies passt wie die Faust aus Auge:
http://www.pctipp.ch/news/sicherheit/44704/langweilige_bugs_und_security_gedoense.html
BILD-Niveau
Unprofessioneller Artikel.
1.:
Linux ist NICHT Unix. Linux ist zwar Unix-ähnlich, basiert aber nicht auf diesem. Linux hat nur wenige dinge direkt übernommen (aber nicht aus dem Code geklaut),z.b. das Rechte-System (wie im Artikel genannt).
Noch dazu ist das letzte offizielle Unix-Release schon ne ganze weile her.
2.:
Habt ihr mal Linux-user zu dem Rechte-System befragt? Im Artikel wird behauptet, effizientes Arbeiten sei mit dem "root kann und darf allea"-Prinzip nicht möglich, da "normale" user demnach nichts dürfen. Das stimmt nicht, im gegenteil. Wenn mehrere Nutzer an einem System arbeiten kann eine Klare Rechte-verteilung mehr von vorteil sein als die von Windows. Wenn mehrere User an einem System arbeiten, kann dies unter Windows dazu führen das User 1 ausversehen daten von User 2 überschreibt. Unter POSIX-systemen ist dies nicht möglich, es sei denn User 1 gibt allen Nutzern das recht seine Daten zu überschreiben. Und wenn in einem Betrieb gearbeitet wird, und die Angestellten a) nicht die ganze Festplatte zu müllen sollen und b) keine programme installieren sollen, ist Linux hier die Bessere wahl, denn der /home-ordner eines Linux-users lässt sich mit root-rechten problemlos in der Größe beschränken. Für den Normalen Benutzer stellt das Root-System keinerlei nachteile da, denn Programme lassen sich unter Linux mindestens genauso schnell installieren wie unter Windows, egal ob man nun das Root-passwort eintippen muss oder nicht. (Und trotzdem ist ein system in dem nur der Root zugriff auf system-dateien hat sicherer!)
3.: Bestimmte aussagen im Bericht die im einzelnen neutral sind, fallen im kontext eindeutig negativ gegen Linux aus. Normale PC-Benutzer erhalten durch diese Ausdruckweisen den eindruck von Objektivität, der in diesem Artikel auf keinen Fall gegeben ist. Hier wird die Sicherheit von Unixoiden Systemen als Nachteil vermittelt und die unsichere, aber unkomplizierte rechteverwaltung von Windows als besser dargestellt, ohne die kernelemente anschaulich zu verdeutlichen. Stattdessen wird hier von Unix berichtet, dessen nachfahre BSD schon in version 4.7 ist, und sicherheitslücken von Windows finden nur erwähnung in Win 95 und Win NT 3.1. Unfair ist daran, das ein normaler user weiß das Win 95 Klar älter ist als XP oder Vista, aber gleichzeitig im glauben gelassen wird, das Linux auf dem Status von Unix hängen geblieben ist.
Mfg
The_Muh
AW: BILD-Niveau
Der wo diesen Artikel geschrieben hat, hat höchstens "Einführung vor Dummies was ist Unix & Windows gelesen…". Mit Security Architektur hat es kaum etwas zu tun… Schilderungen über Prozess und Threaded Programming und daraus Security Architektur abzuleiten ist einfach lächerlich.
Man bekommt leicht der Einduck es gebe keine Threads im Unix, Linux oder OSX..oder dass im Windows alles Multitheaded programmiert wäre..
Der Autor hat sich nich mal Mühe gemach nachzulesen wie Apache "richtig" eigesetzt wird und zwar mit Prozess Forking und Threaded Workers..
Und stellt Apache mit process forking gegenüber IIS mit Threaded Model …
Von wegen Perfromance und Skalierbarkeit…kleine Inteligenzfrage:
Wir haben ein System mit 4 CPU’s, was ist schneller und wieso:
4 Prozesse mit je einem Thread oder ein Prozess mit 4 Threads…
Kommen wir aber zurück zum Thema Security. Ich lasse jedem von sein eigenes menschliches Verstand für ein Moment gebraucht zu machen.
2 Fragen:
1) Auf welchem Betriebssystem braucht man ein Antivirus Software, oder hat man die meisten Antivirus Software und die meisten Viren?
2) Was hilft Antivirus Software bei ungepatches OS.. oder bei OS wo es keine Patches gibt bekannte Security holes..
AW: AW: BILD-Niveau
lustig, ich lese diesen Artikel auch heute zum erstenmal, obwohl schon zwei Jahre alt.
Gestolpert bin ich über diesen Satz: „Das ist auch heute noch so und führt zu erheblichen Schwierigkeiten bei der Implementierung von Sicherheitskonzepten.“ in Bezug auf Root-Rechte.
Wie ist es dann gemeint? Ein Sicherheitskonzept beruht doch darauf, dass man bspw. nicht mit Rootrechten arbeitet und bei jeder systemrelevanten Aufgabe Root-Rechte haben muss. Und es bleibt dabei: Linuxs Stallgeruch ist nunmal Unix mit seinen, schon für professionelle Anwendungen durchdachtes Sicherheitskonzept. Und Windows lernt in der Tat dazu – leider hätte sie längst der Abwärtskompatibilität abschwören müssen.
Dieser Artikel, so interessant er anfing, hätte mehr Sorgfalt und Kompetenz gut getan – schade drum.