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.
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.