Ich hab früher schon mal mit grsecurity gespielt, aber die Installation war etwas hakelig - vor allem wusste man nicht was man wie konfigurieren sollte als Start und wie eine vernünftige rule-based Security anfangen sollte - das ganze war damals eher ein trial-and-error-Gehopse als eine verständliche Installation. Für eine Security-Lösung für ein Betriebssystem ist es aber eher negativ wenn man nicht das Gefühl bekommt zu verstehen was dort passiert.
Mit den aktuellen Versionen von grsecurity hat sich das allerdings weitestgehend geändert. Zum Einen laufen die Patches völlig problemlos in den Kernel rein, zum Anderen gibt es zwei wesentliche Features die den Einstieg leichter machen: einen Quick Guide und RBACK Full System Learning.
Der Quick Guide liefert eine kurze und knappe Installationsanleitung für grsecurity mit einer Startkonfiguration für die ganzen Optionen die schon eine recht gute Basis bietet und problematische Optionen (die manchen Systemdienst ausgrenzen könnten) ausschliesst. Dadurch kriegt man eine grsecurity-Installation hin die eine Menge Schutz bietet, aber normalerweise nicht mit üblichen Systemdiensten in Konflikt gerät. Das ist besonders wichtig für Leute mit Root-Servern - eine falsche Grundkonfiguration könnte sie selber aus dem System aussperren und damit das System unbenutzbar und zum Servicefall machen.
Richtig nett ist aber das Full System Learning: hier wird die RBAC-Engine in ein Logging-System umgewandelt und mitprotokolliert welche Benutzer was ausführen und was für Rechte dafür von Nöten sind. Gesteuert wird das ganze noch durch entsprechende Basisconfigs die verschiedene Systembereiche unterschiedlich einstufen (z.B. sicherstellen das der Benutzer auf alles in seinem Home zugreifen kann, aber nicht zwingend auf alles in diversen Systemverzeichnissen). Man lässt das System einfach ein paar Tage laufen (um auch Cron-Jobs mitzubekommen) und lässt daraus dann eine Startkonfiguration für RBAC erzeugen. Die kann man dann natürlich noch finetunen (sollte man auch später machen - aber als Start ist das schon ganz brauchbar).
RBAC ist im Prinzip eine zweite Sicherheits/Rechte-Schicht oberhalb der klassischen user/group Mechanismen von Linux. Der Root-Benutzer hat also nicht automatisch alle Rechte und Zugriffe auf alle Bereiche. Statt dessen muss ein Benutzer sich parallel zu seiner normalen Anmeldung (die bei Systemdiensten ja implizit durch den Systemstart geschieht!) noch an das RBAC-Subsystem anmelden. Dort werden Regeln hinterlegt die beschreiben wie verschiedene Rollen im System verschiedene Zugriffserlaubnis haben.
Der Vorteil: auch automatisch gestartete Systemdiensten dürfen eben nur auf das zugreifen was in der RBAC-Konfiguration vorgesehen ist - selbst wenn sie unter root-Rechten laufen. Sie haben nur eingeschränkte Fähigkeiten im System bis sie sich am RBAC Subsystem anmelden - dazu ist aber bei den höheren Rollen in der Regel eine manuelle Passworteingabe nötig. Angreifer von aussen können also zwar die von RBAC eingeschränkten Benutzerrechte erlangen, in der Regel aber nicht auf die höheren Rollen hochkommen und daher nicht so weit in das System eingreifen wie es ohne RBAC möglich wäre.
Der Nachteil (sollte man nicht verschweigen): RBAC ist komplex. Und kompliziert. Macht man was falsch, ist das System gesperrt - bei Rootservern die irgendwo draussen im Netz stehen ziemlich lästig. Man sollte also immer Fallback-Strategien haben, damit man ein blockiertes System noch erreichen kann. Zum Beispiel nach Änderungen der RBACs die automatische Aktivierung beim Systemstart auskommentieren, so das bei Problemen ein Reboot das System in einen offeneren Zustand versetzt. Oder einen Notzugang haben, über den man auch ein blockiertes System noch einigermaßen administrieren kann. Generell gilt wie bei allen komplexen Systemen: Pfoten weg wenn man nicht weiss was man tut.
Zusätzlich zu dem sehr mächtigen RBAC bietet grsecurity noch eine ganze Reihe weiterer Mechanismen. Der zweite grosse Block ist pax (wichtig: hier muss eine aktuelle Version benutzt werden, in allen älteren ist ein böses Sicherheitsloch) - ein Subsystem das Bufferoverflow-Attacken einschränkt in dem es Speicherblöcken die Ausführbarkeit und/oder die Schreibbarkeit entzieht. Vor allem wichtig für den Stack, da gerade dort die meissten Buffer-Overflows ansetzen. Pax sorgt dafür, das beschreibbare Bereiche nicht gleichzeitig ausführbar sind.
Ein dritter grösserer Block ist die bessere Absicherung von chroot-Jails. Die klassischen Möglichkeiten für Prozesse aus einem chroot-Jail auszubrechen sind nicht mehr gegeben, da viele dafür nötige Funktionen in einem chroot Jail einfach deaktiviert sind. Gerade für Admins die ihre Dienste in chroot-Jails laufen lassen bietet grsecurity wichtige Hilfsmittel, da eben diese chroot-Jails nur sehr umständlich wirklich ausbruchsicher hinzubekommen waren.
Der Rest von grsecurity befasst sich mit einer ganzen Sammlung von kleineren Patches und Änderungen im System, viele beschäftigen sich mit besserer Randomization von Ports/Sockets/Pids und anderen System-IDs. Dadurch werden Angriffe schwieriger, weil das Verhalten des Systems weniger vorhersagbar ist - besonders wichtig bei diversen local exploits, bei denen zum Beispiel die Kenntniss der PID eines Prozesses dazu genutzt wird um Zugriffe auf Bereiche zu erlangen, die über die PID identifiziert werden (Speicherbereiche, temporäre Files etc.). Auch die Sichtbarkeit von Systemprozessen wird eingeschränkt - normale Benutzer bekommen einfach keinen Zugriff auf die gesamte Prozessliste und werden auch im /proc Filesystem eingeschränkt - und können deshalb nicht so leicht laufende Systemprozesse angreifen.
Eine komplette Liste der Features von grsecurity ist online.
Alles in allem bietet grsecurity eine sehr sinnvolle Zusammenstellung von Sicherheitspatches die jedem Betreiber eines Servers ans Herz gelegt werden sollte - die Möglichkeit von Remote Exploits wird drastisch eingeschränkt und auch die lokale Systemsicherheit durch die RBAC deutlich aufgewertet. Es gibt bei der doch recht einfachen Implementierung des grsecurity-Patches in ein bestehendes System (einfach den Kernel patchen und neu installieren, booten, lernen, aktivieren - fertig) keinen Grund den Patch nicht zum Beispiel auf Rootservern standardmäßig zu nutzen. Eigentlich sollte ein Security-Patch genauso zur Systemeinrichtung gehören wie eine Backupstrategie.
Jetzt wärs natürlich noch schöner wenn die eigentliche Dokumentation des Systems etwas grösser als die man-Pages und ein paar Whitepapers wäre - und vor allem auf aktuellem Stand wäre. Das ist noch immer ein echtes Manko, weil eben das richtige Gefühl das System verstanden zu haben sich ohne qualifizierte Dokumentation nicht so recht einstellen will ...
