Nur 9 kritische Lücken, davon alle durch andere Projekte, bis auf eine nur Browser betroffen und bei der letzten ein DE das hier eh nicht zum Einsatz kommt. Dazu noch alles schnell gefixt. Was will man mehr? Dafür zahlt man gerne Support und genau solche Resultate widersprechen mehreren Punkten der gestern berichteten widerlichen Windows 7 FUD Kampagne. Und wenn sich jetzt noch ein Windows Fan über die Kampagne der FSF beschwert soll er nun ziemlich blamiert das Weite suchen.
Und was ist mit dem letzten Kernel-Local-Root-Exploit? Der dauerte bei RHEL eine Woche, bis er gefixt war. Alle anderen Distributionen waren innerhalb ein oder maximal zwei Tagen gefixt. Erschwerend kam hinzu, daß RH selinux verschlimmbessert hat, so daß dadurch einer der Workarounds nicht griff, also das Problem durch selinux noch schlimmer gemacht wurde als es eh schon war.
Sabbel Sabbel Sabbel... Weil SELinux bei einem Fall Probleme macht ist es schlecht? Es gibt dutzende andere Fälle wo es schützt. Also wenn man keine Ahnung hat lieber geschlossen halten. Zudem ist die sendpage Lüge nicht kritisch gewesen.
In den Fällen, die ich kenne, hat selinux nie geholfen. Ich kenne aber mehr als genug Fälle, in denen selinux ein Schuß ins Knie ist. (Wie in diesem Fall.)
Das der Bug nicht als kritisch _eingestuft_ wird, ändert nichts an der Tatsache, daß er hochkritisch war. Was daran eine Lüge sein soll, kann ich nun wirklich nicht nachvollziehen.
Mit einer willkürlichen Einstufung der Schwere kann man so ziemlich jede Statistik schönreden. Ich muß täglich mit RHEL leben und kann von so manchen Bugs der Distribution erzählen und wie unfähig sich der (kostenpflichtige) Support manchmal anstellt.
Die Problem ließ sich durch einfaches Setzen einer sysctl-Variable vollständig ausschalten; ohne Nebenwirkungen übrigens. Einem RedHat-Admin darf man unterstellen, er schaffe dies, so daß ein paar Tage bis Aufschlagen geänderten Codes ziemlich ungefähr genau egal sein dürften.
Jau, genau diese Antwort habe ich erwartet. Schon getestet, was in so einem Falle passiert? Ich kann Dir etwas helfen, genau garnix. Der Exploit funktioniert nach wie vor. Grund ist, wie schon erwähnt, selinux, das eine solche Lösung adabsurdum führt, da es fehlerhaft implementiert ist. Übrigens betrifft das nur die selinux-Implementierung von RedHat, die anderen Distributoren haben dieses Problem (meines Wissens nach) nicht, bei denen funktioniert die von Dir angesprochene Lösung.
Korrekterweise muß man sagen, daß es eine Lösung gibt, die jedoch auf jeden Fall einen Reboot benötigt, also diesen und noch einen, wenn der neue Kernel kommt (kam, natürlich). Das ist bei nicht allen Systemen machbar.
Red Hat, vielen Dank.
Das der Bug nicht als kritisch _eingestuft_ wird, ändert nichts an der Tatsache, daß er hochkritisch war. Was daran eine Lüge sein soll, kann ich nun wirklich nicht nachvollziehen.
Mit einer willkürlichen Einstufung der Schwere kann man so ziemlich jede Statistik schönreden. Ich muß täglich mit RHEL leben und kann von so manchen Bugs der Distribution erzählen und wie unfähig sich der (kostenpflichtige) Support manchmal anstellt.
Davon abgesehen sit Dein Post substanzlose Schmaehkritik.
Das ändert NICHTS an der Gesamtsituation
Ausnahmen bestätigen wie immer die Regel
Einem RedHat-Admin darf man unterstellen, er schaffe dies, so daß ein paar Tage bis Aufschlagen geänderten Codes ziemlich ungefähr genau egal sein dürften.
Korrekterweise muß man sagen, daß es eine Lösung gibt, die jedoch auf jeden Fall einen Reboot benötigt, also diesen und noch einen, wenn der neue Kernel kommt (kam, natürlich). Das ist bei nicht allen Systemen machbar.