Das ist so nicht korrekt. Weder gibt es GrSecurity nur noch gegen Bares, noch ist GrSecurity aus der Mode. Um genau zu sein gibt es unter Linux nichts Besseres, da es im Vergleich zu übrigen Optionen weitaus effektiver ist. Und der Grund warum die Stable-Patches von GrSecurity nur noch gegen Bares zu haben sind, liegt an missratenen Unternehmen die GrSecurity genutzt und damit Unrat betrieben haben, wodurch das Projekt in Verruf geriet. Genau darum haben Unternehmen nur noch zu zahlen, wenn sie etwas durchgängig Getestetes haben wollen, womit das Geld so gesehen auch der Community zugute kommt. Doch nach wie vor werden die Beta-Patches frei zum Download zur Verfügung gestellt. Auch im Unstable-Repository von Debian ist dieser Beta-Patch immer enthalten, wie auch bereits fertig gepatchte Linux-Kernel zur sofortigen Nutzung.
Nutze jene Linux-Kernel nun schon einige Jahre, und konnte bislang keine essentiellen Probleme feststellen, die eine Nutzung nun problematisch gestaltet hätten. Das einzige womit man sich eben arrangieren muss ist, dass das System beim Erststart erst mal kaputt ist, und entsprechend erst die Restriktionen von etlichen Binarys aufgehoben werden müssen. Aber sofern man sich hier richtig vorbereitet, läuft das an und für sich.
Würde es vermeiden nur zu SELinux oder AppArmor zu greifen, da es hier nur um MACs geht sonst nichts. Und angesichts der unmenschlichen Syntax von SELinux, ist das den Aufwand gar nicht wert. Ein Fehler in der Konfiguration, und schon hat man mitunter dicke Hintertüren produziert. Dagegen wäre AppArmor zwar deutlich einfacher gehalten, hat aber dafür auch wieder Nachteile. Insbesondere weil dessen Sicherheit auf Pfadnamen basiert, und nicht wie bei SELinux auf Labels. Letztlich muss man auch dazu sagen, dass ein Linux-Kernel mit GrSecurity auch mit SELinux und AppArmor zugleich laufen kann, jedoch die anderen untereinander nicht. Doch die wichtigste Eigenschaft bei GrSecurity ist, dass man hier schon direkt am Linux-Kernel ansetzt, ihn erheblich erweitert und entsprechend restriktiv konfiguriert. Das macht es schwieriger mögliche Sicherheitslücken auszunutzen, sowohl im Linux-Kernel selbst als auch bei laufenden Programmen, und prinzipiell profitiert das gesamte System davon, da bspw. Rechte oder Restriktionen jedweder Art nun noch wirksamer und schwerer zu umgehen sind. Hinsichtlich SELinux und AppArmor, langt ein ordentlicher Kernel-Exploit und das war es mit beiden. Und wenn man einmal die Geschichte verfolgt hat, gab es sehr viele Sicherheitslücken in der Vergangenheit, die beim Mainline-Kernel gegriffen haben jedoch nicht beim GrSecurity-Kernel.
Persönlich empfinde Ich hier RBAC als ausserordentlich hilfreich, insbesondere mit dem Auto-Learning-Mode. Sodass ein Nutzer sein System quasi so wie sonst auch benutzt, aber möglichst genau, und im Hintergrund sozusagen das Verhalten aufgezeichnet wird. Danach wird aus jenen Daten automatisch eine Policy erstellt, die im Anschluss auch forciert wird. Ab hier läuft dann nichts anderes mehr, und muss dann entsprechend erst hinzugefügt werden.
Und abgesehen davon, unterteile Ich das System stets in mehrere LVM-Volumes. So kann jeder Bereich einen eigenen Sicherheitskontext bekommen, z.B. Mountpoints wie ro, nodev, noexec, nosuid als Basisgrundlage. Darüber hinaus laufen wichtige Programme stets in einer Sandbox, besonders der Browser, und auch diverse Systemdienste werden so eingeschränkt. Und inkl. strengen iptables, war das an und für sich bislang ausreichend.
Hier noch eine kleine Übersicht, die nicht auf Anhieb sichtbar ist:
https://grsecurity.net/compare.php