[ox] c't-Interview mit OpenBSD-Maintainer
- From: Stefan Merten <smerten oekonux.de>
- Date: Wed, 27 Aug 2003 21:13:10 +0200
Hi!
Anbei ein Interview, dass die c't mit OpenBSD-Maintainer(?) Theo de
Raadt geführt hat.
Mit Freien Grüßen
Stefan
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
aus c't 13/2003, s. 106f.
Erich Bonnert
"Wir machen keine Politik, wir schreiben Software"
Theo de Raadt über Zukunft und Sicherheit von OpenBSD
Anfang Mai hat das OpenBSD-Team um den Kanadier Theo de Raadt die
Version 3.3 des Open-Source-Betriebssystems freigegeben. Mit der
aktuellen Release wollen die Entwickler neue Maßstäbe bei ihrer
obersten Maxime setzen: der Sicherheit.
Unter dem Aspekt der Sicherheit erhielt das Open-Source-Projekt sogar
Fördermittel vom US-Verteidigungsministerium - zumindest bis vor
kurzem. Denn nach einem Zeitungsinterview, in dem sich der Kanadier
kritisch über die Rolle der USA im Irak-Krieg äußerte, stellte die
Defense Advanced Research Projects Agency (DARPA) die Förderung
komplett ein. Erstes Opfer war die Unterstützung für den Hackathon
genannten, jährlichen Workshop der OpenBSD-Entwicklergemeinde.
c't: Was waren die Gründe für die Entscheidung der DARPA, Ihnen die
Fördermittel zu streichen?
de Raadt. Direkt hat uns die DARPA nichts mitgeteilt. Professor
Jonathan Smith von der Universität von Pennsylvania gab uns Bescheid.
dass die Air Force die Förderung für das POSSE-Projekt und damit
OpenBSD zurückgezogen hat. Dann behauptete die DARPA, nur der
Hackathon sei gestrichen. Tatsächlich aber hat die Air Force alle
weiteren Fördergelder eingefroren.
c't: Wie wollen Sie darauf reagieren?
de Raadt: Nun, ich habe mehrere Vermutungen. wo die Gründe liegen
könnten. Aber es nützt mir nichts, darüber Theorien zu verbreiten. Da
die Story bereits zur Genüge in den Medien behandelt wird, werde ich
mich stattdessen darauf konzentrieren, weiter an OpenBSD zu arbeiten.
c't: Und was bedeutet das für die Zukunft von OpenBSD? Die Entwicklung
hing doch bisher stark an den Hackathons.
de Raadt: Richtig, die wichtigsten konzeptionellen Arbeiten und
radikalen Änderungen kommen meistens in den Hackathons zustande.
c't: Wurde der DARPA-Zwischenfall auf dem Hackathon diskutiert? Die
Finanzierung des ganzen Treffens stand doch auf dem Spiel.
de Raadt: Die DARPA ist absolut kein Thema gewesen. Der Zwischenfall
spielt auch keine Rolle. Die Kosten konnten durch Spenden und unsere
knappen Ersparnisse aufgefangen werden. Wir haben genauso viel
geleistet wie sonst auch. Tatsächlich war es unser bisher größter
Hackathon - 53 Leute, glaube ich.
c't: Und was war anders als bei vorhergehenden Hackathons?
de Raadt: Unsere ersten Hackathons sind wir immer mit einer gezielten
"Mission" angegangen. Zum Beispiel in Boston vor zwei Jahren, als wir
einen komplett neuen Paketfilter schrieben. Jetzt läuft der Hackathon
anders, und ich meine auch besser. Dieses Mal gab es rund 20 Teams,
die verschiedene Projekte bearbeitet haben. Dann wurde neu gemischt
und man wendete sich neuen Problemen zu - ein wahnsinnig komplexes und
intensives Klima.
c't: Hat es sich gelohnt?
de Raadt: Ultrasparc III und AMD Hammer wurden zum Laufen gebracht,
ebenso i386 SMP und Mozilla. Hardwareverschlüsselung wurde um den
Faktor 10 beschleunigt. Aber keines von diesen Projekten ist während
des Treffens ganz fertig geworden. Die Teilnehmer sind jetzt wieder zu
Hause - nach elf Tagen Hacken in Calgary waren viele ausgebrannt und
widmen sich jetzt, wie ich, anderen Dingen im Leben. Erst in zwei oder
drei Wochen werden wir die Arbeiten fortführen.
c't: Wird der DARPA-Fall Konsequenzen nach sich ziehen? Wurde über
Veränderungen im Team oder bei den Zuständigkeiten gesprochen?
de Raadt: Nichts hat sich geändert. Niemand hat das Team verlassen.
Wir setzen einfach unsere Arbeit fort. Unser Ziel ist es nicht,
Politik zu machen - wir schreiben Software.
c't: Aber wird es auch ohne Regierungsgelder wie geplant weitergehen?
Bleiben Sie im Zeitplan?
de Raadt: Ja. Allein durch meine Ersparnisse habe ich unsere ersten
zwei Jahre finanziert. Die folgenden vier Jahre haben wir durch
Spenden und den Verkauf von CDs bestritten, die letzten zwei wurden
wir durch die DARPA teilfinanziert. Während dieser Zeit haben wir die
Erlöse aus CDs und Spenden für nebenläufige Projekte verwendet.
Ab sofort werden wir wohl wieder nur von CD-Verkäufen und Spenden
leben müssen. Wir haben niemals jemanden eingestellt oder dafür
bezahlt, für OpenBSD zu arbeiten. Alle Beteiligten betrachten OpenBSD
als Hobby und stellen ihre Arbeitszeit unentgeltlich zur Verfügung.
Danach kehren sie wieder zu ihrem richtigen Job zurück oder nehmen ihr
Studium wieder auf. Für einige wird das jetzt etwas früher der Fall
sein. Aber wir halten uns an unseren Zeitplan. Nächstes Release ist am
1. November, das darauf folgende am 1. Mai 2004. Daran ändert sich
nichts.
c't: Wo sehen Sie die besonderen Stärken und Schwächen von OpenBSD?
de Raadt: Ich bin mir nicht sicher, ob wir etwas Besonderes
darstellen. Wir tun das. woran wir Spaß haben. Verschiedene Leute in
der Gruppe haben unterschiedliche Schwerpunkte. Aber alle fügen sich
in ein Schema, das ich vorgebe, denn Qualität verlangt nun einmal
einen tragfähigen Prozess. Wir verwenden aber außergewöhnlich viel
Zeit auf Fragen der Sicherheit. Oder, wie ich sie lieber nenne.
Qualitätsfragen.
c't: Wie sehen Sie ihre eigene Rolle in dem Projekt, im Vergleich etwa
zu Linus Torvalds innerhalb der Linux-Gemeinschaft?
de Raadt: Ich verfolge das mit seiner Rolle nicht so genau. Meine
Rolle ist die eines wohlwollenden Diktators. Ich gebe die Richtung vor
und bin an fast allen Entscheidungen beteiligt, die die Semantik
betreffen oder den Zeitplan beziehungsweise die Geschwindigkeit der
Entwicklung. Das muss auch so sein, denn ich stelle alle sechs Monate
eine Release aus unserer Software zusammen.
c't: Wie würden Sie Ihren eigenen Führungsstil beschreiben?
de Raadt: Manchmal mit der langen Peitsche, manchmal mit ganz viel
Zuckerbrot.
c't: Wie definieren Sie ein sicheres Betriebssystem? Und wie kommt man
dorthin?
de Raadt: Ein sicheres System ist vollkommen fehlerfrei. Und genau das
ist nicht machbar. Aber wir können wenigstens versuchen, so gut wie
möglich dorthin zu kommen. Die meisten kommerziellen Anbieter
reagieren einfach nur auf Probleme, wir sind stattdessen bemüht, sie
vorwegzunehmen.
c't. Wie schafft man das bei der ständig wachsenden Komplexität?
de Raadt: Wir tun vieles, um unsere Software zu verbessern. Wir gehen
aber immer davon aus, dass sie danach immer noch Fehler enthält. Wir
wollen es verhindern beziehungsweise erschweren, dass diese Fehler
ausgenutzt werden können. Bei jeder Änderung achten wir darauf, dass
alles wie gewohnt funktioniert. Denn semantische Änderungen können
gefährliche Nebenwirkungen auslösen. Darum haben wir damit angefangen,
Code zu überprüfen, nach Bugs zu suchen und Fehler zu beseitigen.
Später haben wir einzelne Codeteile in eine Art Gefängnis eingesperrt.
Dann haben wir ProPolice eingeführt. ProPolice ist so wichtig, das man
es sich unbedingt näher anschauen sollte. Zum Schluss haben wir W^X
ans Laufen gebracht.
c't. In aller Kürze. Was bedeutet W^X und warum ist es so wichtig?
de Raadt: Grob gesagt: Wir versuchen nach Kräften, Seiten ohne
PROT_EXEC (Kennzeichnung einer Speicherseite, dass sie ausführbaren
Code enthält; Anm. d. Red.) nicht ausführbar zu machen. Wohlgemerkt.
Wir versprechen die Ausführbarkeit von Seiten mit PROT_EXEC, aber
nicht, dass Seiten ohne PROT_EXEC nicht ausführbar sind; aber wir
arbeiten dran.
Eines möchte ich aber betonen. ProPolice ist viel wichtiger als W^X
oder andere Techniken, denn es verhindert zusätzlich zu bekannten
Buffer-Overflow-Attacken auch Return-to-libc-Angriffe (siehe Kasten).
Wir haben noch nicht viele Angriffe dieser Art gesehen, aber sie sind
ja auch noch trotz W^X möglich. Das ist ein ernst zu nehmendes
Problem, denn jemand kann dadurch bereits vorhandenen Code verwenden,
um ein System vollständig zu übernehmen oder, schlimmer noch, zu
korrumpieren. W^X nimmt sich anderer Probleme an. Die beiden Techniken
ergänzen sich also.
c't: Müssen Sie für die erhöhte Sicherheit nicht
Kompatibilitätsprobleme in Kauf nehmen? Es wurde bereits über
Schwierigkeiten mit W^X in Java-Umgebungen berichtet.
de Raadt: Da handelt es sich um einen Haufen Lügen von Leuten. die
eindeutig keine Ahnung haben. Unsere Systemaufrufe mprotect() und
mmap() funktionieren genau so wie zuvor, ohne semantische Änderungen.
Jede Anwendung kann jetzt Speicher anfordern, der entweder
beschreibbar (PROT_WRITE) oder ausführbar ist, und wird ihn auch
bekommen. Auf dem Intel x86 oder dem PowerPC können dadurch andere
Objekte ausführbar werden, aber es gibt keine Situation, in der
Anfragen nicht bedient werden. Kein Programm stürzt infolge unserer
Neuerungen ab. Außerdem verlangen moderne CPUs mit getrennten Daten-
und Befehls-Caches ohnehin mprotect()- oder msync()-Aufrufe, damit auf
solch einen programmseitig modifizierten Code ordnungsgemäß
zugegriffen werden kann.
c't: Läuft W^X auch effizient auf Intel-Hardware?
de Raadt: Ja, sogar sehr effizient. Im Release 3.3 schaffen wir es
nicht rechtzeitig, dass es läuft, aber einige der Entwickler verwenden
es schon. Der i386 kann nur eine simple Trennlinie durch den
Speicheradressraum ziehen, das heißt im oberen Adressbereich ist der
Speicher nicht mehr ausführbar. In Shared-Libray-Umgebungen wechselt
sich normalerweise Code mit Daten im Speicher ab. Man kann also nicht
an einer bestimmten Stelle Code und Daten genau trennen. Darum linken
wir unsere ELF-Programme so, dass eine virtuelle Lücke von einem 1
GByte zwischen Code- und Datensegmenten entsteht. Auf diese Weise
können wir den Code für das Hauptprogramm und die Shared Libraries im
unteren Speicherbereich und die dazugehörigen Daten im höheren
Adressbereich platzieren. Wenn eine Applikation Speicher anfragt, der
im höheren Bereich ausgeführt werden muss, kann die Linie zwischen
Code und Daten nach oben verschoben werden, um die POSIX-Semantik
nicht zu verletzen. In diesem Fall wird Speicher ohne PROT_EXEC
effektiv wieder ausführbar. Damit sind wir dann wieder am
Ausgangspunkt angelangt. Applikationen, die so etwas erfordern, sind
allerdings äußerst selten. Und sie werden ganz normal weiter laufen,
da ihre Anfragen nach PROT_EXEC ja gewährt werden.
Vereinfacht gesagt. Für die Intel-Architektur ziehen wir eine
Trennlinie im Speicher. Die ausführbaren Teile befinden sich dann auf
der einen Seite der Linie und die beschreibbaren auf der anderen.
c't: Wie sehen Sie die Diskussion um TCPA und die Palladium-Initiative
von Microsoft?
de Raadt: Diese Technologien interessieren mich nicht.
c't: Wie wäre es denn, wenn die Open-Source-Community über
Alternativen dazu nachdächte! Linus Torvalds scheint sich dafür
erwärmen zu können, eine Art Palladium in Linux einzubauen.
de Raadt: Interessiert mich absolut nicht. Das sollte Sie auch nicht
weiter überraschen, denn es hat überhaupt nichts mit der Sicherheit
von Betriebssystemen zu tun. Sie dürfen mich nicht nach
Geschäftsmodellen fragen, die darauf beruhen, die eigenen Kunden
anzugreifen.
(ola)
________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de