Benutzer renne schrieb:
Konkrete Implementierungen sind z.B. AppArmor oder SELinux
SELinux ist mir bekannt. Ich sehe das Tool allerdings eher im Server-Bereich, wo es zur Absicherung von als anfällig bekannten Server-Prozessen (z.B. Apache mit mod_php) sicher sehr gute Dienste leisten kann. Auf den Desktop fehlen m.E. aber einige wichtige Features: So kann SELinux zum Beispiel nicht interaktiv rückfragen, ob der User im Einzelfall einem Programm nicht doch das Recht gewähren will, eine bestimmte Datei zu öffnen. Dazu jeweils Config-Dateien anzupassen, ist dem Durchschnitts-Nutzer zu hoch.
Eine GUI-Integration von SELinux müsste beispielsweise in der Lage sein, zu erkennen, welche Dateien der Nutzer im Datei-Öffnen-Dialog gewählt hat, und diese - und nur diese - Dateien dann zur Bearbeitung freizugeben. Dazu müsste der Dialog bei heutigen Programmiersprachen (C, C++, Java etc.) wahrscheinlich in einem gesonderten, geschützten Prozess laufen, denn der Datei-Öffnen-Dialog hat ja Zugriff auf alle (für den User lesbaren) Verzeichnisse, die eigentliche App nicht. Diesen Extra-Dialog in einem seperaten Prozess dann GUI-mäßig so zu integrieren, dass er als integraler Bestandteil der Haupt-App erscheint, und zugleich über die GUI nicht doch wieder Exploits von dem einen in den anderen Prozess geschoben werden können, ist schon für sich genommen eine erhebliche Programmieraufgabe. Und es ist nur eine von vielen auf dem Weg zu wirklich fein-granularer Sicherheit auch auf dem Desktop.
End-User-Distributionen, wie Ubuntu-Desktop, verwenden bereits AppArmor. Dabei sind die Sicherheitsprofile natürlich sehr lax konfiguriert, um den Nutzern größtmögliche Freiheit zu bieten.
Genau da liegt das Problem: Weil die Tools eben auf den Admin und nicht auf den Endnutzer zugeschnitten sind, werden sie auf minimalen Regelsatz reduziert oder ganz abgeschaltet.
In einer sicherheitsrelevanten Umgebung ist es eher die Frage, wieviele Mannstunden in die Erstellung der SELinux-Sicherheits-Policies investiert werden, als ein komplett neues Betriebssystem, in welches hunderttausende Mannstunden investiert werden müssten.
Wahrscheinlich reden wir sogar über Millionen Mannstunden, die nötig sind, um das im Editorial angesprochene Sicherheitskonzept zu erforschen, zu formulieren und dann die Umsetzung zu überwachen. Angesichts von Stückzahlen im Bereich von hunderten Millionen (Windows, MacOS/iOS) bzw. Milliarden (Android) sind die Kosten pro Systemkopie aber gering.
Als weit größeres Problem sehe ich übrigens die marktüblichen Programmiersprachen, wie z.B. C, die Programmierfehler, wie z.B. Pufferüberläufe, geradezu herausfordern.
Das ist eine weitere Baustelle. Man wird allerdings im Betriebssystembereich nie umhin kommen, ungeschützt auf den Speicher zu schreiben. In Anwendungen sollte das aber in der Tat nicht mehr passieren.