Unter Unix ist „Impersonation“ stark eingeschränkt. Das ist eine Technologie, die es ermöglicht, dass ein Server-Prozess eine neue Identität annimmt, sobald sich ein Client-Prozess korrekt identifiziert hat. Unix erlaubt ausschließlich Prozessen, die unter root laufen, eine neue Identität anzunehmen.
Typisches Beispiel ist ein SSH-Server: Der SSH-Prozess läuft zunächst unter root. Sobald ein Benutzer eine Verbindung aufbaut, wird ein Tochterprozess geforkt. Nach korrekter Anmeldung nimmt der zweite Prozess die Identität des Benutzers an, siehe Bild 3. Das ist sicherheitstechnisch einwandfrei, bedingt jedoch einen eigenen Prozess für jeden angemeldeten Benutzer, was einen erheblichen Ressourcenbedarf erfordern kann.
Sicherheit versus Performance: Oft ein Konflikt
Aus Performancegründen wäre es besser, mit nur einem Server-Prozess und verschiedenen Threads zu arbeiten. Windows bietet die Möglichkeit, einzelnen Threads eines Prozesses unterschiedliche Identitäten zuzuweisen. Ein Server-Prozess kann dabei zunächst mit einem Account gestartet werden, der sehr wenige Rechte besitzt. Nötig ist nur das Recht „Annehmen der Clientidentität nach Authentifizierung“. Ein Client-Prozess, der sich identifiziert, bekommt anschließend einen eigenen Thread, der die Identität des Client-Benutzers annimmt. Für einen FTP-Server bedeutet das beispielsweise, dass der Thread einfach versucht, eine Datei zu öffnen, die der Benutzer anfordert. Hat der Benutzer keine Berechtigung, so erhält der Thread einen Access-Denied-Fehler.
Auch unter Unix ließe sich eine Lösung mit Posix-Threads realisieren. Dann bleibt aber nur die Möglichkeit, alle Threads der Benutzer mit der Root-Identität laufen zu lassen. Ob ein Benutzer berechtigt ist, auf eine Datei zuzugreifen, muss der Server-Prozess selbst prüfen.
Auf den ersten Blick scheint ein Multi-Threaded-Server unter Windows sicherer als unter Unix. Hat ein Server unter Unix einen Bug, etwa einen Pufferüberlauf, so kann es gelingen, beliebigen Code auszuführen. Unter Unix hat ein Angreifer dann sofort Root-Rechte, während er unter Windows nur die Rechte des angemeldeten Benutzers, in diesem Fall seine eigenen, besitzt.
Das reicht jedoch aus, um beispielsweise einen Botnetz-Client zu installieren. Dies kann ein Benutzer absichtlich, aber auch versehentlich veranlassen, wenn sein eigener Rechner ebenfalls verseucht ist.
Ferner bedeutet eine Lösung mit Threads sowohl unter Unix als auch unter Windows immer das Risiko, dass Passwörter ausspioniert werden, wenn ein Angreifer eine Sicherheitslücke ausnutzen kann. Gelingt ihm die Ausführung von Code, so hat er Zugriff auf den gesamten virtuellen Speicher des Prozesses, auch auf den Master-Thread, der die Nutzer authentifiziert.
In der Praxis hat das dazu geführt, dass Entwickler von Serveranwendungen unter Unix meist mit Tochterprozessen arbeiten. Wird die Client-Server-Verbindung von einem eigenen Prozess verwaltet, kann ein Angreifer grundsätzlich keine Verbindungsdaten anderer Clients ausspionieren. Unter Windows werden häufig Thread-Lösungen implementiert.
Fehlerfreie Security-Architektur nicht realistisch
Beide Lösungen sind dann sicher, wenn sich in der Server-Anwendung, in den verwendeten Libraries und im Betriebssystem keine Bugs befinden, die ein Angreifer ausnutzen kann. Das ist jedoch nicht realistisch.
Schaut man in die Details einiger Serveranwendungen, dann finden sich erhebliche Mängel. Ein Beispiel ist SMB-Filesharing. Windows verwendet eine Thread-Lösung mit den beschriebenen Risiken. Unter Unix verwendet Samba eine Implementierung mit Tochterprozessen.
Solange Dateien geöffnet sind, arbeitet jeder Tochterprozess mit der Identität des Benutzers. Wenn nach einer gewissen Zeit der Inaktivität die TCP-Verbindung geschlossen wird, kehrt dieser Tochterprozess zur Identität root zurück. Bild 4 zeigt, dass der Samba-Prozess 3251 zunächst unter dem Benutzer root gestartet wird, danach unter tinah arbeitet und später wieder unter root.
Dass dies überhaupt möglich ist, hängt damit zusammen, dass die unterschiedlichen Unix-Versionen eine Rückkehr zum ursprünglichen Benutzer unterschiedlich handhaben. Linux verbietet explizit eine Rückkehr zur root, wenn man das Posix-API setuid verwendet. Andere APIs, beispielsweise seteuid und setreuid, erlauben dies explizit.
Der Prozess arbeitet zwar nur dann unter root, wenn keine Client-Verbindung geöffnet ist, jedoch kann eingeschleuster Schadcode jederzeit die Root-Rechte ohne Legitimierung anfordern. Sicherheitstechnisch hätte Samba Privilege-Separation implementieren müssen, wie es beispielsweise OpenSSH vormacht. Das bedingt natürlich zwei Prozesse pro Client-Verbindung und damit mehr Ressourcen.
SMB-Filesharing sperrt fast jede Firefall in der Default-Konfiguration. Die Implementierungen in Windows und Linux sind vom Konzept her nicht sicher genug, wenngleich aus völlig unterschiedlichen Gründen. Performanceüberlegungen stehen im Vordergrund. Einen SSH-Zugang ermöglicht hingegen jeder Hoster über das Internet. Security-Purist Theo de Raadt stellt bei OpenSSH eine saubere Security-Architektur vor jede Performanceüberlegung.
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.