"Symlink-Attacken" technisch vorbeugen: dynamische umask für Symlinks
Hauke Laging
heute wurde bei heise eine Sicherheitslücke gemeldet, die in
Zusammenhang mit Symlinks steht:
http://www.heise.de/security/news/meldung/62808
Daraufhin habe ich mich gefragt, warum Symlinks überhaupt in dieser
Weise behandelt werden, und überlegt, wie es besser gemacht werden
könnte. Nun ist das Problem natürlich nicht neu, mein Gedanke
vermutlich auch nicht :-), aber vielleicht hat ja irgendwer Lust,
mal das passende Stichwort zu nennen, was ich nicht bedacht habe.
Mein Posting dort:
http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=8621741&forum_id=83211
Wäre nicht schon viel gewonnen, wenn die rechtebezogene Transparenz
von Symlinks aufgehoben würde? Es sollte so 'ne Art umask für Links
geben: Wenn ein Link aufgerufen wird, wird erst mal geprüft, welche
Rechte der "Owner" des Links (wird ja immerhin eh gespeichert) in
dem Moment hätte, und mehr bekommt dann auch der Aufrufer nicht.
Auch nicht als root :-)
Das kann man ja gerne optional realisieren. Ich kann mir nicht
vorstellen, dass das in der Praxis eine messbare Einschränkung wäre,
denn wann legt man mal Links für einen anderen User an, damit der
die mit höheren Rechten nutzt? So was gibt's doch gar nicht.
CU
Hauke
--
http://www.hauke-laging.de/ideen/
---
Wie können 59.054.087 Leute nur so dumm sein?
Florian Weimer
> Das kann man ja gerne optional realisieren. Ich kann mir nicht
> vorstellen, dass das in der Praxis eine messbare Einschränkung wäre,
> denn wann legt man mal Links für einen anderen User an, damit der
> die mit höheren Rechten nutzt? So was gibt's doch gar nicht.
Inwiefern mit "höheren Rechten"? Die meisten unverzichtbaren Symlinks
haben diese Form.
Das wirkliche Problem ist bei diesem Fall schließlich, daß jemand ein
für alle schreibbares Verzeichnis verwendet und auf O_EXCL verzichtet.
Das ist meist auch ohne Symlinks ein Problem.
Für die verbleibenden Fälle wie /tmp gibt es Patches, wenn man so
etwas mag.
Hauke Laging
> Inwiefern mit "höheren Rechten"?
Damit meine ich: User hl legt einen Symlink auf /etc/passwd an, hat
nur Leserechte. Nun kommt irgend jemand aus der Gruppe root, nutzt
diesen Link und hat Schreib-Lese-Rechte auf die Datei. Also "mehr"
Rechte, "höhere" ist schlecht formuliert.
> Die meisten unverzichtbaren Symlinks haben diese Form.
Welche? Wann wird mal gezielt ein Link von einem User angelegt, der
nur lesen darf, und von einem User benutzt, der auch schreiben darf
(und soll)?
> Das wirkliche Problem ist bei diesem Fall schließlich, daß jemand
> ein für alle schreibbares Verzeichnis verwendet und auf O_EXCL
> verzichtet. Das ist meist auch ohne Symlinks ein Problem.
Ich verstehe den Sinn des Flags nicht, habe extra noch mal
nachgelesen. O_NOFOLLOW hätte ich verstanden.
> Für die verbleibenden Fälle wie /tmp gibt es Patches, wenn man so
> etwas mag.
Von einem Patch rede ich ja ;-)
Juergen P. Meier
> Florian Weimer schrieb am Montag, 15. August 2005 21:15:
>
>> Inwiefern mit "höheren Rechten"?
>
> Damit meine ich: User hl legt einen Symlink auf /etc/passwd an, hat
> nur Leserechte. Nun kommt irgend jemand aus der Gruppe root, nutzt
> diesen Link und hat Schreib-Lese-Rechte auf die Datei. Also "mehr"
> Rechte, "höhere" ist schlecht formuliert.
Und?
>> Die meisten unverzichtbaren Symlinks haben diese Form.
>
> Welche? Wann wird mal gezielt ein Link von einem User angelegt, der
> nur lesen darf, und von einem User benutzt, der auch schreiben darf
> (und soll)?
Unverzichtbare Symlinks werden selten von Usern in User-beschreibbaren
Verzeichnissen angelegt.
>> Das wirkliche Problem ist bei diesem Fall schließlich, daß jemand
>> ein für alle schreibbares Verzeichnis verwendet und auf O_EXCL
>> verzichtet. Das ist meist auch ohne Symlinks ein Problem.
>
> Ich verstehe den Sinn des Flags nicht, habe extra noch mal
> nachgelesen. O_NOFOLLOW hätte ich verstanden.
Es geht um Symlinkattacken.
>> Für die verbleibenden Fälle wie /tmp gibt es Patches, wenn man so
>> etwas mag.
>
> Von einem Patch rede ich ja ;-)
Der ist Unnoetig bis potentiell stoerend.
Man darf halt nicht mit UID=0 "surfen", dann passiert dieser Angriff
nicht.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Hauke Laging
> Und?
Hältst Du das für eine sinnvolle Nachfrage?
> Unverzichtbare Symlinks werden selten von Usern in
> User-beschreibbaren Verzeichnissen angelegt.
Genau das sage ich ja.
>> Ich verstehe den Sinn des Flags nicht, habe extra noch mal
>> nachgelesen. O_NOFOLLOW hätte ich verstanden.
>
> Es geht um Symlinkattacken.
Ach.
> Man darf halt nicht mit UID=0 "surfen", dann passiert dieser
> Angriff nicht.
Diese Aussage ist ja nun völlig daneben. Symlinkattacken ziehen ihre
"Berechtigung" ja gerade daraus, dass der Angreifer keine
root-Rechte hat.
Juergen P. Meier
> Juergen P. Meier schrieb am Dienstag, 16. August 2005 06:36:
>
>> Und?
>
> Hältst Du das für eine sinnvolle Nachfrage?
Ja. Leider hast du deinen Teil nicht mitzitiert.
>> Unverzichtbare Symlinks werden selten von Usern in
>> User-beschreibbaren Verzeichnissen angelegt.
>
> Genau das sage ich ja.
Ach.
>>> Ich verstehe den Sinn des Flags nicht, habe extra noch mal
>>> nachgelesen. O_NOFOLLOW hätte ich verstanden.
>>
>> Es geht um Symlinkattacken.
>
> Ach.
Du hast dir angeschaut, wie die Mehrzahl der Symlink-Angriffsklassen
funktioneren, im Detail?
>> Man darf halt nicht mit UID=0 "surfen", dann passiert dieser
>> Angriff nicht.
>
> Diese Aussage ist ja nun völlig daneben. Symlinkattacken ziehen ihre
> "Berechtigung" ja gerade daraus, dass der Angreifer keine
> root-Rechte hat.
Ein Erfolgreicher Symlink-Angriff braucht einen Angreifer und einen
Angegriffenen. Letzterer muss Bloed Genug[tm] sein, auf den Angriff
hereinzufallen. Wer mit UID=0 auf einem Mehrbenutzersystem nicht
aufpasst, ist Selbst Schuld[tm].
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Florian Weimer
> Florian Weimer schrieb am Montag, 15. August 2005 21:15:
>
>> Inwiefern mit "höheren Rechten"?
>
> Damit meine ich: User hl legt einen Symlink auf /etc/passwd an, hat
> nur Leserechte. Nun kommt irgend jemand aus der Gruppe root, nutzt
> diesen Link und hat Schreib-Lese-Rechte auf die Datei. Also "mehr"
> Rechte, "höhere" ist schlecht formuliert.
Symlinks funktionieren so nicht. Wenn der Link gesetzt wird, muß noch
nicht einmal das Ziel feststehen. Dummerweise werden derartige
Symlinks von einigen Anwendungen genutzt, um Daten zu speichern.
>> Die meisten unverzichtbaren Symlinks haben diese Form.
>
> Welche?
Wenn man /home auf /mnt/storage/1/home umziehen will, zum Beispiel.
> Wann wird mal gezielt ein Link von einem User angelegt, der nur
> lesen darf, und von einem User benutzt, der auch schreiben darf (und
> soll)?
Einzelne Dateien kann man sowieso fast immer kopieren.
>> Das wirkliche Problem ist bei diesem Fall schließlich, daß jemand
>> ein für alle schreibbares Verzeichnis verwendet und auf O_EXCL
>> verzichtet. Das ist meist auch ohne Symlinks ein Problem.
>
> Ich verstehe den Sinn des Flags nicht, habe extra noch mal
> nachgelesen. O_NOFOLLOW hätte ich verstanden.
O_EXCL löst schon das zugrundeliegende Problem bei schreibbaren
Verzeichnissen. O_NOFOLLOW hingegen zerstört die Symlink-Transparenz
und macht Dinge wie den oben erwähnten Umzug unmöglich.
Stefan Reuther
> Hauke Laging <usenet_...@hauke-laging.de>:
>>Diese Aussage ist ja nun völlig daneben. Symlinkattacken ziehen ihre
>>"Berechtigung" ja gerade daraus, dass der Angreifer keine
>>root-Rechte hat.
>
> Ein Erfolgreicher Symlink-Angriff braucht einen Angreifer und einen
> Angegriffenen. Letzterer muss Bloed Genug[tm] sein, auf den Angriff
> hereinzufallen. Wer mit UID=0 auf einem Mehrbenutzersystem nicht
> aufpasst, ist Selbst Schuld[tm].
Ausgangspunkt war ja wohl, dass es sich bei demjenigen, der "mit UID=0
surft", um ein Programmpaket handelt, welches vom Packager fehlerhaft
konfiguriert war. Dieses Programmpaket erzeugt nun Dateien in einem
Verzeichnis mit Mode 777, was mittels Symlink zum Überschreiben von
/etc/passwd genutzt werden kann.
Das heißt, ein Admin ist nicht Blöd Genug[tm] und Selbst Schuld[tm] (man
verwendet fertige Pakete ja nun gerade, um sich nicht um jeden Sch***
selbst kümmern zu müssen), sondern das Paket ist einfach kaputt. Hauke
wollte durch eine Änderung des Verhaltens von Symlinks erreichen, dass
derart kaputte Pakete nicht mehr einfach ausgenutzt werden können.
Prinzipiell ist das ja gar keine schlechte Idee. Es schlägt in die
gleiche Kerbe wie "W^X" oder "PAX" und wie die ganzen tollen
Marketingnamen für das Feature "nicht-ausführbarer Stack" alle heißen.
Allerdings erreicht man damit auch keine absolute Sicherheit gegen diese
Angriffsklasse. Wenn ich nichts übersehe, erreicht man als Angreifer mit
einem Hardlink genau das gleiche. Und zumindest auf kleinen Systemen
(wie z.B. allen meinen privaten Installationen) ist /etc auf der selben
Partition wie /var und /tmp.
Mir fällt allerdings auch kein Grund ein, der gegen die Änderung
sprechen würde. Außer "ist schon immer so gewesen".
Stefan
Adrian Knoth
> Ausgangspunkt war ja wohl, dass es sich bei demjenigen, der "mit UID=0
> surft", um ein Programmpaket handelt, welches vom Packager fehlerhaft
> konfiguriert war. Dieses Programmpaket erzeugt nun Dateien in einem
> Verzeichnis mit Mode 777, was mittels Symlink zum Überschreiben von
> /etc/passwd genutzt werden kann.
Ja, wegen eines vergessenen chmods strickt man nicht den halben Kernel
um.
> Das heißt, ein Admin ist nicht Blöd Genug[tm] und Selbst Schuld[tm] (man
> verwendet fertige Pakete ja nun gerade, um sich nicht um jeden Sch***
> selbst kümmern zu müssen), sondern das Paket ist einfach kaputt. Hauke
Sicherlich kann man nicht alle Stellen im Filesystem ständig im
Auge behalten (zumindest nicht ohne Tools), aber bei der clamav-
Installation hatte ich trotz Pakets darauf geachtet, welche
Permissions die Verzeichnisse bekommen, unter welchem User der
ganze Spaß läuft (insbesondere im Zusammenhang mit amavasd-new)
und wie die Logs rotiert werden.
Es scheint ohnehin keine schlechte Idee zu sein, zumindest auf
Servern die Software, die mittelbar dem Netz exportiert ist,
etwas genauer anzuschauen.
> wollte durch eine Änderung des Verhaltens von Symlinks erreichen, dass
> derart kaputte Pakete nicht mehr einfach ausgenutzt werden können.
Was willst du denn ändern? Prinzipiell gibt es nur zwei Möglichkeiten:
a) Erstellen von symlinks auf höher priorisierte Nutzer verhindern
Das scheidet aus, weil man dann z.B. als User nicht ein Systemverzeichnis
in sein Home linken kann. Oder 1000 andere Beispiele dieser Art, symlink
auf das CDROM-Laufwerk, whatever.
b) Symlinks veranlassen das Setzen der UID für den Lesevorgang auf
den Nutzer des Symlinkerstellers
Das würde bedeuten, daß ein UID-0-Programm auf einmal "Permission denied"
erhält, wenn es versucht, auf einen Symlink zu schreiben, der von einem
anderen (niedriger privilegierten Nutzer) angelegt wurde.
Im Falle eines Angriffes ist das wünschenswert, es würde aber tonnenweise
semantische Konvention brechen. Du wunderst dich, daß trotz SUID
dein Programm keine Schreibrechte hätte - das kracht doch an allen
Ecken und Enden.
(Hypothetisches Beispiel: "news" und "uucp" teilen sich einen Spool,
dort gibt es diverse Symlinks. Wenn jetzt ein bsmtp-batcher mit
root-Rechten daherkommt und nicht auf den Symlink schreiben kann,
weil er entweder zu news oder uucp gemacht wird und damit im
konkreten Fall nicht die erforderlichen Rechte hat, dann kracht es.
Sicherlich kann man den Batcher umkonfigurieren, aber es ist eben
semantisch gewollte Transparenz von Symlinks, die dadurch verlorengeht.
(ich muß zukünftig zwischen tatsächlicher und gesymlinkter Pfadangabe
unterscheiden. Das ist nicht gewollt. Alternativ kann ich auch den
symlink als root setzen, dann ändert sich entweder das Beispiel auf
einen non-root-Nutzer oder es greift die Argumentation mit der
korrekten Permission.))
Was macht man, wenn uucp einen news-Symlink besuchen will? Die
Rechte von news? Die Rechte von uucp? Das Maximum aus diesen
Rechten? Würde im Fall von root-Symlinks ausscheiden. Das
Minimum? Würde die Rechte von uucp unnötig beschneiden.
Wie gesagt, die Pfadtransparenz geht dir völlig verloren. Selbst
wenn man die Implementierung sicher und sinnvoll hinbekommt,
es wird semantisch nur chaotisch (um am Beispiel zu bleiben: selbst
wenn man root-symlinks transparent macht, könnten scriptbasiert
erzeugte news-symlinks von uucp nicht mehr besucht werden)
Überhaupt gehört das ganze UID-Konzept abgeschafft.
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Person1: Geil. Morgen um 9 muss ich Präsentation halten. ÖRKS!
Person2: Morgen um 9 werde ich eine Kaffeetasse halten.
Hauke Laging
>>> Die meisten unverzichtbaren Symlinks haben diese Form.
>>
>> Welche?
>
> Wenn man /home auf /mnt/storage/1/home umziehen will, zum Beispiel.
Du verstehst mich irgendwie falsch. Deinen Beispiellink kann nur root
anlegen, der hat auch Schreibrechte auf das Zielverzeichnis, also
wäre umask in dem Fall 0 - keine Einschränkungen.
> Einzelne Dateien kann man sowieso fast immer kopieren.
Das ist ja auch kein Sicherheitsproblem. passwd wird ja nicht über
den Inhalt, sondern seine Position im Dateisystem erkannt. ;-)
> O_EXCL löst schon das zugrundeliegende Problem bei schreibbaren
> Verzeichnissen.
OK, durch welche Funktion, was löst das aus? Aus der man page werde
ich diesbezüglich nicht schlau.
Hauke Laging
> Du hast dir angeschaut, wie die Mehrzahl der
> Symlink-Angriffsklassen funktioneren, im Detail?
Nein, natürlich nicht, wie aus meinem Ausgangsposting auch
hervorgeht. Deshalb habe ich ja hier gefragt.
>> Diese Aussage ist ja nun völlig daneben. Symlinkattacken ziehen
>> ihre "Berechtigung" ja gerade daraus, dass der Angreifer keine
>> root-Rechte hat.
>
> Ein Erfolgreicher Symlink-Angriff braucht einen Angreifer und einen
> Angegriffenen. Letzterer muss Bloed Genug[tm] sein, auf den Angriff
> hereinzufallen. Wer mit UID=0 auf einem Mehrbenutzersystem nicht
> aufpasst, ist Selbst Schuld[tm].
Wie schon jemand anderer schrieb, hat das mit UID 0 eben wenig zu
tun. Ansonsten könnte man argumentieren, dass die User auch an
Kernelbugs schuld seien, immerhin hätten sie den Fehler ja im
Quellcode vorher finden können...
Adrian Knoth
>> Ein Erfolgreicher Symlink-Angriff braucht einen Angreifer und einen
>> Angegriffenen. Letzterer muss Bloed Genug[tm] sein, auf den Angriff
>> hereinzufallen. Wer mit UID=0 auf einem Mehrbenutzersystem nicht
>> aufpasst, ist Selbst Schuld[tm].
> Wie schon jemand anderer schrieb, hat das mit UID 0 eben wenig zu
> tun.
Aber sicher hat das was mit UID 0 zu tun. Ein Virenscanner muß
nicht als root laufen.
Und ob man nun "surft" oder stellvertretend ein Programm nach
Viren suchen läßt ist immer eine UID-Frage.
Üblicherweise ist jedes Programm kritisch zu hinterfragen, das
als root durch die Gegend läuft. Das gilt für einen Maildaemon
genauso wie für den Webserver.
Insbesondere ist das ja auch der Sinn hinter Priviledge-separation.
Daher ist Kapersky der Vorwurf zu machen, weshalb er unnötig
mit root-Rechten rumloggt statt dafür einen unprivilegierten Nutzer
zu verwenden.
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
AIDS: Alles ist Detlefs Schuld
Hauke Laging
> Ja, wegen eines vergessenen chmods strickt man nicht den halben
> Kernel um.
Ich habe mir noch nie Kernelcode angesehen, aber einen Zugriffscheck
um eine Abfrage des Symlinkerstellers zu erweitern und pro
Verzeichnis und am Ende für die Datei nicht nur für einen, sondern
für zwei User die Rechte zu prüfen, kann kaum problematisch sein.
> Installation hatte ich trotz Pakets darauf geachtet, welche
Wenn man ein Problem zentral lösen kann, dann sollte man es tun.
> Was willst du denn ändern? Prinzipiell gibt es nur zwei
> Möglichkeiten:
Plus die, die ich skizziert habe...
> a) Erstellen von symlinks auf höher priorisierte Nutzer verhindern
> b) Symlinks veranlassen das Setzen der UID für den Lesevorgang auf
> den Nutzer des Symlinkerstellers
Also noch mal: Aus den Rechten des Symlinkerstellers wird eine
(invertierte) umask für den aktuellen Zugriff.
> Das würde bedeuten, daß ein UID-0-Programm auf einmal "Permission
> denied" erhält, wenn es versucht, auf einen Symlink zu schreiben,
> der von einem anderen (niedriger privilegierten Nutzer) angelegt
> wurde.
Nur dann, wenn der Nutzer keine Schreibrechte hatte. Und wann bitte
soll das Szenario mal sinnvoll sein? Für diesen Ausnahmefall, für
den hier noch kein einziges Beispiel gebracht wurde, kann die
UID-0-Anwendung immer noch auf ein readlink und einen
eigenverantwortlichen Zugriff auf sein Ziel zurückgreifen.
> Im Falle eines Angriffes ist das wünschenswert, es würde aber
> tonnenweise semantische Konvention brechen.
Bitte mal ein einziges praktisches Beispiel.
> Du wunderst dich, daß
> trotz SUID dein Programm keine Schreibrechte hätte - das kracht
> doch an allen Ecken und Enden.
Theoretisch denkbar, nur das Beispiel aus der Praxis vermisse ich
noch. Das wäre ein klassisches abschaltbares Feature. 99% der
Linux-Nutzer haben keine so komischen SUID-Programme und könnten von
dieser Funktion profitieren.
> (Hypothetisches Beispiel: "news" und "uucp" teilen sich einen
> Spool, dort gibt es diverse Symlinks. Wenn jetzt ein bsmtp-batcher
> mit root-Rechten daherkommt und nicht auf den Symlink schreiben
> kann, weil er entweder zu news oder uucp gemacht wird und damit im
> konkreten Fall nicht die erforderlichen Rechte hat, dann kracht es.
Sowohl news als auch uucp haben ja wohl Schreibrechte auf die Ziele
ihrer Symlinks. Also kein Problem für root.
> Was macht man, wenn uucp einen news-Symlink besuchen will? Die
> Rechte von news? Die Rechte von uucp?
An den userbezogenen Rechten ändert sich nichts, es gibt lediglich am
Ende der Prüfung ein umask-artiges Blocken einzelner Rechte.
Wahrscheinlich löst man schon alle Probleme, wenn man dieses Feature
auf Schreibrechte beschränkt.
> Das Maximum aus diesen
> Rechten? Würde im Fall von root-Symlinks ausscheiden. Das
> Minimum? Würde die Rechte von uucp unnötig beschneiden.
Hier wird gar nix beschnitten. news setzt einen Link auf den eigenen
Datenbereich, hat damit alle Rechte, und als Folge davon wird auch
der Zugriff von uucp nicht über das bekannte Maß hinaus beschränkt.
> Wie gesagt, die Pfadtransparenz geht dir völlig verloren.
Gewagte Behauptung.
Hauke Laging
> Aber sicher hat das was mit UID 0 zu tun. Ein Virenscanner muß
> nicht als root laufen.
>
> Und ob man nun "surft" oder stellvertretend ein Programm nach
> Viren suchen läßt ist immer eine UID-Frage.
>
> Üblicherweise ist jedes Programm kritisch zu hinterfragen, das
> als root durch die Gegend läuft. Das gilt für einen Maildaemon
> genauso wie für den Webserver.
>
> Insbesondere ist das ja auch der Sinn hinter Priviledge-separation.
> Daher ist Kapersky der Vorwurf zu machen, weshalb er unnötig
> mit root-Rechten rumloggt statt dafür einen unprivilegierten Nutzer
> zu verwenden.
Du hast mit allem Recht - daher sei mir das lange Quoting mal
verziehen. <g> Aber letztlich ist mit diesen Aspekten keine Wertung
meines Vorschlags möglich. Ich will einen zentralen Mechanismus, der
Sicherheitslücken weniger gefährlich macht. Dem kann man nicht
entgegenhalten, dass man ja zukünftig einfach mal fehlerfreie
Software schreiben könnte. Das eine hat mit dem anderen exakt nichts
zu tun.
Relevant für die Beurteilung sind folgende Fragen:
a) Wird das Problem (zu einem vernünftigen Teil) gelöst?
b) Ist die Implementierung einfach?
c) Hätte diese Änderung in der Praxis Probleme zur Folge?
Hannah Schroeter
Stefan Reuther <stefa...@arcor.de> wrote:
>[...]
>Prinzipiell ist das ja gar keine schlechte Idee. Es schlägt in die
>gleiche Kerbe wie "W^X" oder "PAX" und wie die ganzen tollen
>Marketingnamen für das Feature "nicht-ausführbarer Stack" alle heißen.
JFTR, "W^X" macht nicht nur den Stack nicht-ausführbar. Und es
funktioniert auch auf x86-CPUs, die an sich kein getrenntes
"execute"-Bit in den Pagetables hat.
>[...]
Gruß,
Hannah.
Florian Weimer
>>Prinzipiell ist das ja gar keine schlechte Idee. Es schlägt in die
>>gleiche Kerbe wie "W^X" oder "PAX" und wie die ganzen tollen
>>Marketingnamen für das Feature "nicht-ausführbarer Stack" alle heißen.
>
> JFTR, "W^X" macht nicht nur den Stack nicht-ausführbar.
Und damit das *überhaupt* einen Effekt hat, muß man den Adreßraum
durcheinanderwürfeln, so daß viele Lisp-Implementierungen nicht mehr
laufen. Oder wie war das?
Rainer Weikusat
[...]
> Und zumindest auf kleinen Systemen (wie z.B. allen meinen privaten
> Installationen) ist /etc auf der selben Partition wie /var und
> /tmp.
/tmp ist auch auf 'grossen Installationen' typischerweise Bestandteil
von /, weil es den 'durchschnittlichen UNIX(*)-admin' einfach nicht
interessiert, ob sein System muellkonfiguriert ist, solange er nur die
Arbeit sparen kann, es anders zu machen.
Hannah Schroeter
Zumindest clisp lief mit W^X durchaus, nur nicht mit der zusätzlichen
extremen Randomisierung von malloc in OpenBSD nach 3.7.
Gruß,
Hannah.
Simon Krahnke
> Zumindest clisp lief mit W^X durchaus, nur nicht mit der zusätzlichen
> extremen Randomisierung von malloc in OpenBSD nach 3.7.
Warum das nicht?
mfg, simon .... l