Open Source im professionellen Einsatz
Linux-Magazin 04/2014

Kernel-News

1165

Mehr Sicherheit fürs Sandboxing

Der russische Entwickler Viktor Porton kritisiert das Sandbox-Kommando von SE Linux. Er schreibt, Programme in der Sandbox könnten immer noch neue Prozesse außerhalb erzeugen oder den Systemcall »setsid()« aufrufen, um auszubrechen. Er schlägt vor, jedem Prozess in der Sandbox ein neues Feld als Sandbox-ID hinzuzufügen. Kindprozesse erben diese ID und unterliegen dann den gleichen Beschränkungen wie ihr Erzeuger.

Den Vorschlag, dafür Cgroups zu verwenden, nahm er gerne an. Doch da schaltete sich Andy Lutomirski ein, er schrieb: "Meiner Meinung nach sind Cgroups ein völlig gescheiterter Versuch, eine Schnittstelle für normale Programme zu schaffen. Es wird sogar immer schlimmer." In einer weiteren Mail geht Andy aber auf Viktors ursprünglichen Vorschlag ein. Er empfiehlt, statt einer weiteren ID das Kernelfeature Subreaper zu verwenden, das es seit Linux 3.4 gibt. Es verfolgt die Abstammung von Prozessen und teilt entfernten Vorfahren mit, wenn deren Nachkommen sich beenden. Andy möchte Subreaper mit einem weiteren Modus ausstatten, der ganze Prozessbäume kontrolliert und ein API bereitstellt, über das man allen Prozessen ein Signal schicken kann, etwa um sie zu beenden. So soll kein Prozess mehr aus der Sandbox ausbüchsen.

Viktor wendet ein, dass dann die Anwendungen den neuen Subreaper-Modus unterstützen müssten. Dabei seien es gerade diese Programme, denen er nicht traue und die er deshalb in eine Sandbox sperre. Andy präzisiert, nicht die fremde Software, sondern der Sandbox-Mechanismus müsse das Feature unterstützen, denn die fraglichen Prozesse sollten als Kinder der Sandbox laufen.

Ein anderer Ansatz stammt von Joshua Brindle. Er schlägt vor, die Sandbox durch einen Seccomp-Filter sicherer zu machen, der die verfügbaren Systemcalls einschränkt. Auf diese Weise ließe sich beispielsweise »setsid()« in den Griff bekommen.

Viktor hält das für keine passende Lösung für sein Szenario. Er möchte bestimmte Subnetze für die Sandbox sperren, und das könne Seccomp nicht. In seinem Weblog http://portonsoft.wordpress.com veröffentlicht er weitere Überlegungen zum Thema, die interessanterweise doch auf Cgroups setzen.

Die SE-Linux-Sandbox des Red-Hat-Entwicklers Dan Walsh (hier auf dem Linuxtag 2011) finden manche Entwickler nicht sicher genug.

Ein bisschen getrollt: Linux, BKL und BSD

Auch die Nachricht eines so genannten Trolls kann zu interessanten Diskussionen auf der Kernel-Mailingliste führen. Im Januar schlug ein Störenfried mit dem Pseudonym Antti Heikkinen vor, Linux in der Sprache Perl neu zu schreiben, denn das Betriebssystem sei aufgebläht und schlecht entworfen. Ein anderer Troll fügte hinzu: "Linux hatte länger als die Konkurrenz ein Big Kernel Lock (BKL). Es wurde nie ordentlich entworfen, Free BSD dagegen ist organisierter und einheitlicher."

Theodore Ts'o parierte gekonnt: "Linux hat länger am BKL festgehalten, weil es SMP schon länger als die Konkurrenz unterstützt. BKL sind wir endgültig Mitte 2012 losgeworden. Dagegen hatten Free BSD, Net BSD und Open BSD noch im Jahr 2013 ein äquivalentes Giant Lock in einigen Subsystemen."

Er fuhr fort: "Natürlich skaliert Linux schon lange besser als die BSD-Familie, SGI etwa verwendet es auf Systemen mit Hunderten Prozessoren, und Linux-Anwender betreiben schon ein Jahrzehnt lang Rechner mit 32 oder 64 CPUs. Free BSD dagegen rühmte sich erst 2013 seiner verbesserten Skalierbarkeit auf 16 Prozessoren."

Zum Thema Trolle bemerkte Ted: "Mein Lieblingsvorschlag dieser Art stammt aus den frühen Neunzigern und lautet, BSD 4.3 nach Emacs Lisp zu portieren, damit man das komplette System unter GNU Emacs betreiben kann."

Vorsichtig am ABI kratzen

Der Keyring-Maintainer David Howells hat neulich ein heikles Thema auf die Tagesordnung gebracht. Einige Kerberos-Entwickler hatten ihn gebeten, die Systemcalls »add_key(« ) und »request_key()« zu ändern, dazu einige Kernelfunktionen.

Insbesondere wünschten sie sich, dass die Bibliothek Libkrb5 bei einem Fehler den Session-Keyring als Fallback benutzen kann. Existiert der Keyring aber nicht, legen Kinit und der Kernel derzeit automatisch einen an, der jedoch wieder verschwindet, wenn Kinit sich beendet.

David erwog ein paar Lösungen, von denen einige den Kernel berührten, andere ihn unangetastet lassen. Die Kerberos-Entwickler könnten beispielsweise aus dem Userspace einen Session-Keyring anlegen. So käme es nicht dazu, dass Kinit einen erzeugt – und man müsste nichts im Kernel ändern.

Daneben fand er aber auch gute Argumente für Anpassungen im Kernel, denn der brauche ja nicht stillschweigend einen neuen Session-Keyring anzulegen. Stattdessen könne er den User-Session-Keyring als Fallback verwenden. Nach Davids Ansicht würde diese Änderung die meisten Prozesse nicht stören.

Da dies aber eine Änderung des Kernel-ABI bedeuteten würde, fragte David vorsichtig auf der Mailingliste an. Linus Torvalds antwortete, indem er die eiserne ABI-Regel des Kernels zitierte: "Sollte jemand die Änderung zu spüren bekommen, machen wir sie wieder rückgängig. In anderen Worten: Änderungen sind nicht vollkommen tabu, aber sie dürfen keine anderen Programme stören."

Daneben schrieb Linus: "Ehrlich gesagt kann ich das nicht beurteilen. Deine Änderung hört sich vernünftig an, aber wer weiß, was in den Distributionen vor sich geht. Wir müssen sehr vorsichtig sein und den Kerberos-Leuten klarmachen, dass wir die Änderung gnadenlos zurücknehmen werden, wenn sie bestehenden Benutzern Probleme macht."

2.6.34.x am Ende

Der finnische Entwickler Aaro Koskinen hat sich besorgt erkundigt, ob es denn für den Kernelzweig 2.6.34.x keine Updates mehr gebe. Dessen Maintainer, Paul Gortmaker von Wind River, hatte bereits im Juli 2013 angekündigt, den Zweig in den Ruhestand zu versetzen. Paul antwortete, er plane noch eine weitere Ausgabe. Wenn das End of Life (EOL) erreicht sei, werde er es auf der Kernel-Homepage bekanntgeben.

H. Peter Anvin merkte an, es sei schon mehr als ein Jahr seit der letzten 2.6.34-Release vergangen. Damit habe dieser Zweig fünf Monate Rückstand gegenüber 2.6.32, und es fehlten einige Securitypatches. Daraufhin brachte Paul noch eine Version heraus, mittlerweile ist 2.6.34.15 aber als EOL markiert.

Probleme mit sscanf()

Der Intel-Entwickler Bruce W. Allen hat der Mailingliste einen möglichen Bug in der »sscanf()« -Implementierung des Kernels gemeldet. Die Funktion liest eine Zeichenkette aus mehreren Teilen und teilt sie in mehrere Stücke, deren Länge vorgegeben ist. Bruce schrieb, während »sscanf()« aus der C-Bibliothek korrekt funktioniere, setze die Version im Kernel eines der Ergebnisse auf 0.

Al Viro konnte das Problem bis zu einem Patch des Suse-Entwicklers Jan Beulich vom Dezember 2012 zurückverfolgen. Der wollte das Verhalten der Funktion eigentlich besser an den Standard anpassen: Der Anwender sollte für jeden Teilstring die gewünschte Byte-Länge angeben dürfen. Um das zu erreichen, verwirft Jans Code die überzähligen Zeichen der Eingabe. Doch wirft er zu viel weg.

In seiner gründlichen Art vergrub sich Al weiter im Code von »sscanf()« und förderte weitere Probleme zutage. Linus Torvalds fand die ganze Sache viel zu kompliziert. Er schlug vor, dem Problem auszuweichen und Feldgrößen in »sscanf()« gar nicht zu unterstützen – allerdings nur dann, wenn niemand sie benutzt. (Zack Brown/mhu)

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.