Openwall Linux Security Patch

[kater]

Benutzt jemand o.g. Patch? Bin gerade am Kompilieren. Mal schauen, was es bringt. Teste die Maschine anschliessend ausgiebig.

Auszug aus der README:

" Linux kernel patch from the Openwall Project.
Overview.
This patch is a collection of security-related features for the Linux
kernel, all configurable via the new 'Security options' configuration
section. In addition to the new features, some versions of the patch contain various security fixes. The number of such fixes changes from
version to version, as some are becoming obsolete (such as because of
the same problem getting fixed with a new kernel release), while other
security issues are discovered."

 

[kater]

Funktioniert tadellos, kann ich nur empfehlen.

 

[gage_]

Habe den auch mal getestet, auch diverse Security-Extensions fuer andere *X (kommerzielle wie z.B. Argus Pitbull LX und Foundation, und freie). Generell ist da nichts Falsches dran, viele machen Dinge, die fuer jedes *X Standard sein sollten (Mandatory Access Control, Capabilities, Compartmented Mode, Role Based Access Control, UID 0 Priviledge Removal).

Trotzdem setze ich solche Patches nicht auf Produktionsmaschinen ein. Die Benutzergruppe solcher Patches ist einfach wesentlich kleiner als die von offiziellen Releases, demzufolge ist auch die Wahrscheinlichkeit kleiner, dass Sicherheitsloecher in diesen Patches gefunden und veroeffentlicht werden.

 

[kater]

Ich habe den Patch auf meiner WS eingespielt und von daher nicht gerade in eine produktive Umgebung wie z.b. einen Server gepatcht.

Jedoch macht mich bei deinem Posting etwas stutzig: Du hast Recht, wenn du sagst, dass die Entwickler beim vanilla Kernel mehr sind und daher theoretisch (!) schneller/besser debuggen/fixen können.
Aber da setzt Openwall gar nicht an, sondern er merzt gravierende Fehler im vanilla Kernel aus, die schon längst hätten gefixt werden müssen, oder wegen der Kompatibilität und Bequemlichkeit _nicht_ (absichtlich!) gefixt werden.

 

[gage_]

Original geschrieben von kater
Aber da setzt Openwall gar nicht an, sondern er merzt gravierende Fehler im vanilla Kernel aus, die schon längst hätten gefixt werden müssen, oder wegen der Kompatibilität und Bequemlichkeit _nicht_ (absichtlich!) gefixt werden.

Jo, der Openwall Ansatz ist natuerlich nicht schlecht (Code Audits, deshalb benutze ich auch OpenBSD Vanilla, weil da das ganze OS geauditet wird ) aber:

Wo neuer Code geschrieben wird, werden Fehler gemacht. Wo Bugs gefixed werden, werden neue geschaffen. Das ist erstmal prinzipiell wahr, egal ob sich das Coding/Fixing auf Security bezieht oder nicht. Weil's in der Natur des Programmierers liegt, Fehler zu machen.

Ist die Nutzerbasis dieses neuen Codes klein, ist auch die Wahrscheinlichkeit kleiner, dass der Fehler gefunden und publiziert wird. Der beste Weg ist daher, wenn Code Audits und Bug Fixes da gemacht werden, wo sie auch am besten in die Weiterentwicklung einfliessen - im Main Branch der Software.

Um Dir ein Beispiel zu geben: Es ist sehr einfach, wenn man mit besten Security-Willen ein strcat() durch ein strncat() ersetzt, eine Situation zu schaffen wo ploetzlich ein nicht-NUL-terminierter String im Speicher haengt, und das strcat() vor dem Fix gar nicht exploitable war (fuer diese Situation haben die OpenBSDler strlcat() implementiert, aber das ist eine andere Geschichte ).

 

[kater]

Mit anderen Worten:

Ich hätte mir das Patchen und Recompiling sparen können, da sehrwahrscheinlich im gepatchten Kernelcode auch bad code existiert (was ich nicht bezweifle), welcher nur durchs Patchen eingebunden wurde.

Hm, so weit so gut.

Nur, Openwall schliesst Löcher, die lange schon bekannt waren, für die man jedoch noch nicht die Zeit hatte, sie zu schliessen. Neu ist eigentlich nicht viel. Gut, ein Fix bleibt ein Fix, sprich Code, der auch fehlerbehaftet ist/sein kann.

 

[gage_]

Jo, das hast Du soweit ganz richtig verstanden ... ob es sinnlos war, ist schwierig zu beurteilen, und genau da liegt das Problem

Du musst abschaetzen, ob Du dem zusaetzlichen "Vendor" in Sachen Disclosure, und Kenntnis seiner Basistechnologie und Vorhandensein einer erheblichen Benutzermenge vertraust.

 

[gage_]

Jo, das hast Du soweit ganz richtig verstanden ... ob es sinnlos war, ist schwierig zu beurteilen, und genau da liegt das Problem

Du musst abschaetzen, ob Du dem zusaetzlichen "Vendor" in Sachen Disclosure, und Kenntnis seiner Basistechnologie (die Software die gefixed wird. Das o.g. Problem tritt eher nicht auf, wenn jemand die Software genau kennt, die er da anfasst) und Vorhandensein einer erheblichen Benutzermenge vertraust.

 

[kater]

Jetzt muss ich mir nochmals den Kopf zerbrechen