Linux-Sicherheit damals und heute
Auf esecurityplanet.com gibt es einen schönen Artikel, wie sich Linux in Sachen Sicherheit über die Jahre entwickelt hat und sogar musste. Linux sei von Natur aus kein sicheres Betriebssystem. Der Grund hierfür ist, dass Linux auf UNIX basiert, das 1969 entwickelt wurde. Damals kümmerte man sich weniger um Sicherheit. Dieser Umstand garantiert eine große Anzahl an Sicherheitslöchern, schrieb Dennis Ritchie 1979 in seinem Dokument “On the Security of UNIX”.
Auf der LinuxCon in Boston sprach Red Hats James Morris, ein Kernel-Entwickler aus Australien, wie sich Linux in den letzten zehn Jahren in Sachen Sicherheit gemausert hat. Als UNIX Ende der 60er entwickelt wurde, dachte jeder, dass wir heute bereits fliegende Autos haben, sagte Morris. Stattdessen müssen wir uns mit Facebook rumplagen. Einerseits benutzen wir Computer in diesen Tagen, wovon man vor 40 Jahren nur geträumt hat. Dennoch müssen wir mit Betriebssystemen arbeiten, die vor Jahrzehnten entworfen wurden, fügt Morris an.
Hier liege die Herausforderung für Entwickler. Um Linux abzusichern, mussten Programmierer Sicherheits-Komponenten an und um den Kernel schweißen. UNIX DAC war das Original-Sicherheits-Konzept für Linux. Danach folgte POSIX, ACL, private und PID Namespaces, Kryptografie, SELinux, Smack, TOMOYO, AppArmor und so weiter.
Das größte Problem an der Sicherheits-Geschichte ist die große Auswahl. Anwender könnten sich davon abschrecken lassen, weil sie nicht wissen, welche sie verwenden sollen. Gibt man einem Menschen eine Liste mit vielen Zutaten und fordert ihn auf, aus irgendwelchen damit eine gute Suppe zu kochen, könnte das schief gehen. Es ist einfacher, ein vordefiniertes Rezept zu verwenden.
Die Artenvielfalt sei in der Tat hinderlich, sichere Linux-Arbeitsstationen und -Server aufzusetzen. Ein Systemadministrator müsse sich zum Beispiel für eine Lösung entscheiden. Viele dieser verschiedenen Sicherheits-Technologien lösen alle ähnliche Probleme, tun dies aber leicht unterschiedlich. Novell hat zum Beispiel einen Vergleich zwischen AppArmor und SELinux veröffentlicht. Dieser zeigt, dass AppArmor ein einfacheres Konfigurations-Format hat.
Des Weiteren müsse man sich Gedanken über Netzwerk-, Storage-Sicherheit und Schadcode-Schutz machen. Somit müsse man weitere Software wie Netfilter, NuFW, fsnotify, TALPA oder DazukoFS einsetzen.
Das größte Problem sei jedoch den Menschen einzuhämmern, dass Sicherheit notwendig ist, sagte Morris. Anschnallpflicht könne man per Gesetz verankern. Sichere Linux-Server und -Workstations aufzusetzen bedürfe Überzeugungsarbeit. Anstatt Anwender mit Sicherheits-Software zu überhäufen, müsse man Sicherheit zu transparent wie möglich machen.
Transparenz sei eines der angestrebten Ziele von AppArmor, sagte Tony Jones von SUSE. Wenn man AppArmor in ein System einpflegt, müsse man AppArmor-Profile entwerfen. Die Anwendungen müsse man jedoch nicht verändern. Entfernt der Anwender AppArmor, ändert sich am Funktionieren des Systems nichts. Allerdings ist es nicht mehr durch AppArmor abgesichert. Auch wenn SELinux etwas komplizierter zu sein scheint, ist Transparenz auch hier das Hauptziel.
Vorteil von Transparenz sei, dass es die größte Sicherheitsgefahr – den Menschen – verkleinern kann. Menschen würden immer den Weg des geringsten Widerstandes gehen. Wenn sich Systemadministratoren mit komplizierten Dokumentationen und Konfigurations-Dateien herumplagen müssten, um ein System sicherer zu machen, würden sich vielen davon entmutigen lassen. Das erhöhe die Wahrscheinlichkeit, dass Systeme unsicher bleiben.
Für Sicherheits-Ninja Bruce Schneier ist Sicherheit im Wesentlichen ein Problem des Menschen.
