 gehört, die deutsche Übersetzung des Vortrags Cloud ABI hier auf dem 32C3 und wir hören jetzt einen Vortrag über eine POSIX-Laufzeit-Umgebung, in der mit Sandboxing gearbeitet wird. Ja, danke schön. Schön, so einen vollen Raum hier zu sehen, es sind, glaube ich, nur noch so ungefähr zehn freie Sitze hier. Das letzte Mal, als ich diesen Talk in Deutschland gehalten habe, das war, glaube ich, im September bei einer Konferenz in der Nähe von Bonn und was ein bisschen schlecht war, mein Talk lag da genau am Ende des ersten Tages, das war genau zu dem Zeitpunkt, als sie angefangen haben, zu grillen und das führte dann dazu, dass ich nur ungefähr zehn oder zwanzig Leute in meinem Talk hatte und heute haben wir genau das Gegenteil, das ist, oh, jetzt ist mein Laptop ausgegangen, ah ja, das ist besser. Ja, bevor ich anfange, will ich mich ein bisschen vorstellen, ganz schnell, mein Name ist Ed Rauten, ich bin ein Open Source Hacker aus den Niederlanden und ungefähr 2002 habe ich angefangen zu studieren und da habe ich angefangen, mich für Betriebssysteme zu interessieren und ich habe erst Windows benutzt, später dann Linux und ein oder zwei Jahre später habe ich dann auch FreeBSD und OpenBSD benutzt, eine Zeit lang und na ja, diese üblichen Open Source Betriebssysteme habe ich zumindest einmal ausprobiert und eine ganze Reihe von ihnen habe ich nicht wirklich gemocht, aber das eine, was dann, wo ich dann hängen geblieben bin, das war FreeBSD, ihr seht das vielleicht an meinem T-Shirt, aber ich benutze natürlich auch Linux. Endletzten Jahres habe ich eine Weile in Deutschland gelebt und habe da auch gearbeitet, aber es gab da etwas, was mich immer so ein bisschen gestört hat. Ich habe meine eigene kleine IT Consulting Firma gegründet, um etwas zu machen, was ich bei meinem vorigen Arbeitgeber nicht machen konnte. Okay, also das war so groß zu mir und jetzt reden wir mal über Cloud ABI, das ist ja das eigentliche Thema dieses Vortrags, aber ich will zunächst mal erklären, was meine Meinung nach falsch mit Unix ist. Eine ganze Reihe, Leute werden sich fragen, was soll dann falsch an Unix sein, das ist doch nur Getrolle, was du hier machst. Unix ist ein tolles Betriebssystem, was ich jetzt schon seit über einem Jahrzehnt benutze, aber es gibt zwei Sachen, die mich, meine Meinung nach, nie richtig gelöst wurden und das erste ist, dass System motiviert einen nicht wirklichen Software auf eine sichere Art und Weise laufen zu lassen und es motiviert einen auch nicht wieder verwendbare und testbare Software zu schreiben. Also schauen wir uns mal einen ganz einfachen Use Case an. Wir haben also irgendwo ein Linux Server und wollen darauf einen Web Server laufen lassen. Welcher genau ist eigentlich völlig egal, irgendein Web Server. Diese Web Server muss eigentlich nur eine handvoll Sachen machen. Wenn man mal genau darüber nachdenkt, musst du eigentlich sehr wenige Sachen machen. Er muss also eingehende TCP-IP-Verbindungen akzeptieren, über die er HTTP-Get-Requests entgegennimmt und irgendwie verarbeitet. Er muss wahrscheinlich einige Dateien, die irgendwo auf Festplattes sind, zugreifen. Vielleicht gibt es irgendwo einen Verzeichnisbaum und vielleicht gibt es irgendwo noch ein Python oder PHP-Script, was sich dann irgendwie zu einer Datenbank verbindet. Also da muss er auch darauf zugreifen können, irgendwelche Transaktionen machen und das Ergebnis wird dann über die TCP-IP-Verbindungen zurückgesendet. Also wenn man sich mal so anschaut und vergleicht mit allem, was ein Unix-Programm machen könnte, dann ist das eigentlich nur ein ganz kleiner Ausschnitt der Funktionalität, die Unix bereitstellt. Aber sobald ein Programm wie ein Web Server komprimitiert ist, dann kann ein Angreifer alles machen, was auf der Maschine möglich ist, wo der Web Server läuft. Also eine ganze Menge Sachen. Er könnte zum Beispiel das komplette Route-Verzeichnis zu einem Torball verpacken und das kann dann die ganze Welt lesen. Das ist vielleicht noch nicht wirklich sehr schädlich, aber das ganze Dateisystem dagegen abzusichern ist in der Praxis ziemlich schwer und was vielleicht eine Firma da macht, das mag vielleicht einen Angreifer auf der anderen Seite des Netz nicht wirklich beeindrucken. Was kann ein Angreifer noch machen? Er kann zum Beispiel Set UID auf einigen der Utilities setzen und damit kriegt man eine ganz große Angriffsfläche in sein Betriebssystem rein. Also es ist eine ganze Reihe lästiger Sachen, die ein Angreifer machen kann. Also wenn ein Angreifer in den Web Server einbricht, kann er zum Beispiel einen Service installieren, der ihm erlaubt, sich auf dem System einzulocken. Und wenn man danach sein Web Server updated auf eine neue Version, dann hat der Angreifer vielleicht vorher schon einen Cron Job installiert, der alle paar Minuten dafür sorgt, dass diese Spector wieder erzeugt wird. Und im schlimmsten Fall kann der Angreifer das ganze System auch in einen Botnet-Knoten verwandeln und zum Beispiel Spam aussenden oder ähnliche Sachen machen. Das heißt es gibt also einen riesigen Unterschied zwischen dem, was ein Programm unter UNIX können sollte und was es wirklich kann. Und das ist halt einfach wie das UNIX Sicherheitsmodell funktioniert. Und im Laufe der Zeit haben wir gesehen, dass es da verschiedene Frameworks gab, die von Leuten entwickelt wurden, um das Ganze ein bisschen besser zu machen. Und meiner Meinung nach kann man die in zwei verschiedene Kategorien einteilen. Das erste ist sozusagen, dass man einfach mehr Zugriffskontrolle hinzufügt zu dem System. Traditionelle UNIX-Berechtigungen sind nicht granular genug. Man kann nicht genau genug festlegen, was genau eingeschränkt werden soll, zum Beispiel jetzt im Falle von einem Web Server. Und das muss also erweitert werden. Und Linux kann man sehen, dass zum Beispiel SE-Linux oder App-Armor in euch erlaubt, Sicherheitspolices festzulegen. Und die sind dann sozusagen separat von den Dateisystem-Berechtigungen. Und auf diese Art und Weise kann man also diese Applikationen weiter einschränken. Aber meiner Meinung nach ist es keine richtige Lösung dieses Problems, denn was dann passiert ist sozusagen ein Softwareentwickler, entwickelt ein Web Server und dann gibt er seinen Code zu den Leuten, die die Distributionen erstellen. Und diese Leute müssen die Security-Polices schreiben. Und die verstehen vielleicht gar nicht genau, wie die Applikation funktioniert und was die Applikation alles benötigt. Und in manchen Fällen müssen vielleicht die End-Benutzer diese Sicherheitsrichtlinien modifizieren. Und ich denke nicht, dass das das ist, was wie es sein sollte. Es macht es eigentlich unnötig schwer. Und wenn wir jetzt mal zu dem Beispiel unseres Web Servers zurückgehen, wenn man zum Beispiel das Route Verzeichnis für den Web Server ändert in eurer Konfigurationsdatei, dann muss man das gleiche auch in diese Sicherheitsrichtlinien AppArmor updaten. Und wenn der Benutzer das versucht und aus irgendeinem Grund funktioniert es nachher nicht mehr, weil er vergessen hat, die Sicherheitsrichtlinie zu ändern, dann sieht er im Grunde nur, dass dies oder je der Fehler wird von AppArmor verursacht. Also was macht der End-Benutzer? Er schaltet einfach AppArmor auf seinem System ab. Und deshalb ist meiner Meinung nach, funktionieren diese Art von Systemen einfach nicht richtig. Und dann gibt es noch eine zweite Klasse von Systemen. Und ich nenne das gerne capability-based. Na ja, capability hat vielleicht nicht wirklich was damit zu tun. Aber lassen wir uns einfach mal sagen, wir können im Grunde die Applikationen in eine Art Container reintun, so ähnlich wie wir das mit dem Capsicons unter BSD machen. Und was man dann macht, man nimmt einfach seinen Web Server, zum Beispiel Web Server und startet den als normalen Unix-Prozess. Und das erste, was dann passiert, ist der Pass, die Konfigurationsdatei. Und die wiederum liste zum Beispiel die IP-Adressen auf, an denen der Web Server lauschen soll und auch das Verzeichnis, wo das Routverzeichnungs-Webservers liegt. Und alle diese Netzwerkverbindungen und Verzeichnungen werden dann geöffnet. Und sobald dieser Teil vollständig ist, dann wird eine spezielle Routine aufgerufen. Die nennt sich Cap-Enter. Und im Grunde wird damit ein Flagbit im Kernel gesetzt. Und der Kernel weiß dann, dass dieser Prozess jetzt alle Capabilities hat gebraucht. Und ab diesem Moment wird jeder in Anführungszeichen gefährliche Aufruf mit der Fehlermählung Not Capable beantwortet. Und was das bedeutet, ist im Grunde, beispielsweise der Netzwerks-Socket, der geöffnet wurde, weil er in diesem Konfigurationsdatei angegeben war. Natürlich ist es okay, auf diesem Socke zu lauschen und eingehende Verbindungen zu akzeptieren. Das heißt also, wenn eine Verbindung da reinkommt, dann ist es okay, die Verbindung anzunehmen und zu lesen und zu schreiben. Das ist alles sicher. Es ist ebenfalls sicher, Dateien innerhalb des Routverzeichnungs-Webservers zu öffnen. Aber was zum Beispiel nicht sicher ist, ist eine x-bliebige Datei auf der Festballe zu öffnen. Also zum Beispiel, slashetc slash passwd zu öffnen. Und da was reinzuschreiben, ist nicht erlaubt. Und jede andere Datei natürlich auch nicht. Und so funktioniert Capsicum. Es verwandelt das System sozusagen in ein System, was ein capability-basiertes Sicherheitsmodell benutzt. Es gibt also keinen globalen Standstatus, den ein Prozess hat, sondern ein Prozess hat quasi eine ganze, einen Sack voll capabilities, die der Prozess braucht, um die Ressourcen auf dem System zuzugreifen. Und einige Applikationen in FreeBSD benutzen dieses Modell schon. Also zum Beispiel DHC Client, TCP-Dump und einige andere TCP-Dump ist ein sehr gutes Beispiel hierfür. Das Einzige, was dieses Programm machen muss, ist, wenn es startet, muss es eigentlich nur den Berkeley Packet Filter öffnen, um Netzwerk-Traffic mitzuschneiden. Und es muss einen Datei-Descript eroffen haben, um Nachrichten auf das Terminal zu schreiben. Und nachdem es das gemacht hat, kann es Cap-Enter aufrufen. Und wenn ein Angreifer irgendwie es erreicht, zum Beispiel ein Buffer Overflow in TCP-Dump herzustellen, dann besteht wenig bis gar kein Risiko. Und TCP-Dump, wenn man mal drüber nachdenkt, ist eigentlich voller verschiedener Parse. TCP-Dump kann hunderte verschiedene Netzwerk- Protokolle parsen und kann sie die Hand haben und kann alle möglichen interessanten Felder in Applesheaders beispielsweise auswerten. Und es gibt also eine gewisse Chance, dass da ein Buffer Overflow in TCP-Dump lauert. Und ein Angreifer könnte beispielsweise irgendwelchen zufällige Daten über das Netzwerk schicken und darauf warten, dass ein Buffer Overflow in TCP-Dump eintritt. Und wenn das zum Beispiel in einem Prozess passiert, der unter der Autorisierung eines Rootusers läuft, dann kann man damit voll Zugriff auf das System erlangen. Also für solche Unix Utilities ist das wirklich ein brauchbares Sicherheitsmodell. Meine Erfahrung nach, ich habe Capsicum in den letzten Jahren angefangen zu benutzen, habe ein bisschen mit rumgespielt und es funktioniert wirklich, es macht genau das, was es sagt. Die Implementierung auf FreeBSD ist ziemlich robust, das Design dahinter ist okay. Ich habe allerdings eine Sache festgestellt, die ist ein bisschen schwierig gemacht, das auf einer größeren Ebene einzusetzen, alles was über die Komplexität von Pingen hinausgeht. Da wird es ein bisschen schwierig, das einzusetzen, es skaliert also nicht sehr gut. Und was ich so festgestellt habe, ist Code mag es nicht, wenn man auf einmal etwas abschaltet, auf das der Code sich verlässt. Es gibt zum Beispiel eine, naja eigentlich zwei verschiedene Cryptolibraries, ich sage jetzt nicht welche, aber was diese Cryptolibraries machen, sie versuchen, DevU Random zu öffnen und wenn das nicht funktioniert, was macht die, was macht die Library dann? Gibt es eine Fehlermeldung, beendet es sich? Nein, nicht wirklich, sondern sie benutzt dann einfach die aktuelle Zeit oder die User ID oder ähnliches und benutzt das als Seed für den Random Number Generator. Zum Beispiel die Zeit ist ja sowas, die ist ja wirklich zufällig. Das ist, also es ist eigentlich keine gute Sache. Wenn man also Capsicum nicht verwendet, dann ist das ziemlich sicher, weil ja DevU Random kann man immer öffnen, aber sobald man CapEnter benutzt und man hat das vorhin nicht auf U-Random zugegriffen, dann kann auf einmal die Library U-Random nicht mehr benutzen und gerät in einen unsicheren Status. Und es gibt eine ganze Reihe weiterer etwas ärgerlicher Sachen, die ich gesehen habe. Zum Beispiel Zeitzone, wenn man also CapEnter benutzt, bevor man die lokale Zeit benutzt, dann kann das Programm anschließend nicht mehr ETC Local Time zugreifen. Wenn man aber es mindestens einmal macht, bevor man CapEnter aufruft, dann funktioniert das. Das selbe gilt für Localisierung. Sobald man einmal ein CapEnter drin ist, kann man also keine Buchstabenkonvertierung oder ähnliches mehr machen. Also es ist ein bisschen unschön an der Stelle. Und was ich gesehen habe, wenn man eine große Unix-Applikation benutzt und macht dann einen CapEnter aufruf irgendwo rein, dann wird das Programm einfach in einem schwer abzufangenen Weg einfach abstürzen. Und man braucht dann Wochen oder sogar Monate, bis man das alles wieder zum Laufen kriegt. Es gibt also keine richtige Anleitung, wie man das richtig macht. Man sieht also sehr viel bei kleineren Unix-Applikationen in FreeBSD, wie ich schon erwähnt habe. Und bei Applikationen, wo man den Code selber geschrieben hat, aber es ist nicht so, dass die meisten Unix-Applikationen das wirklich benutzen können. Wenn man also einfach auf seinem System PS mal eingibt, da sieht man vielleicht eine oder zwei Prozesse, die Capsicum wirklich benutzen. Und das ist so die Sache, die ich nicht so an Capsicum mag. Sie funktionieren für diese künstlichen oder selbst erstellten Use Cases, aber nicht für diese ganze Software, die man so in echten Leben findet. Ein zweites Problem, was ich mit der Unix-Sicherheit habe, ist Unix macht es ziemlich schwer, eine irgendwelche Applikationen, die man aus dem Internet ausgeführt hat, auf eine sichere Art und Weise auszuführen. Wenn man also ein expliktes Binary ausführt, das man aus dem Internet geladen hat, dann kann einem das das ganze System zerschießen. Wenn man das in einem Container wie zum Beispiel Docker ausführt, dann wird das Ganze etwas sicherer. Die Docker-Leute achten also darauf, dass man dann nicht einfach x-beliebige Binarys ausführen kann. Das Ganze innerhalb einer VM auszuführen ist sicher, aber vielleicht nicht immer, es gibt auf diese Konferenz, glaube ich, einen weiteren Talk, der sich damit befasst, wie man die Sicherheit von VMs aushebeln kann. Aber für die meisten Leute ist es wahrscheinlich sicher genug. Aber ich habe mich halt gefragt, warum ist es unter Unix nicht möglich, irgendwelche x-beliebige Applikationen einfach auf eine sichere Art und Weise auszuführen? Warum muss ich eine VM installieren, um das zu machen? Warum muss ich VirtualBox installieren und da noch ein virtuelles Festplattenverband anzulegen, um einfach eine Applikation sicher auszuführen? Warum gibt es keinen einfacheren Weg? Also als ich vorhin gesagt habe, der zweite Problem ist das wegen wiederverwendbarer Testabilität. Wenn ich diese erste Slides geschrieben habe, hatte ich ein Problem, um zu erklären, was ich habe mit meiner, mit Wiederverwendbarkeit und Testabilität und Testbarkeit. Also ich habe eine Analogie und statt ein Unix zu erklären, werde ich über Softwareentwicklung generell und programmieren und vielleicht ein bisschen Java programmieren. Wenn du dein einfaches Software, ein einfaches Webserver, würdest du sowas schreiben? Was Webserver? Und das ist ein Konstruktor und der Konstruktor setzt ein bisschen Member und initialisiert die Klasse und das erstellte eine TCP-Socket, die hört auf Board 80 und dann hat ein Verzeichnis, wo die Daten gespeichert werden. Das funktioniert, aber die meisten Leute würde sagen, das ist nicht so richtig ein Code, so wie man das schreiben wird und dass es für Code Review geben würde. Hoffentlich bei der Reviewer kommen würde und euch eins auf den Schädel verpassen, weil das ist überhaupt nicht verwendbar und das ist immer Board 80 und das ist immer den Bund und deswegen erweitert man den Konstruktor, damit man ergibt ein paar Parameter wie zum Beispiel den Boardnummer, den Roots, Verzeichnis, das geht schon in eine gute Richtung. Aber ein Veteran Java Programmierer kommt und sagt, hey, das ist immer noch nicht richtig. Du brauchst Schnittstellen, Interfaces oder mehr Abtrakktionen, mehr Schichten und das ist einfach zu testen zu machen. Die meisten Java Programme würden das einfach statt ein TCP-Socket zu erstellen, machst du das einfach einen abstrakten Socket und genauso wie dem File System zu machen, brauchst du das nicht einfach so mit einer Schnittstelle, die einfach eine Funktion anbietet, get file-content um die man übergibt ein Dateiname und bekommt man den Datei in Hals, in einem Puffer und da kann man mit dieser Klasse testen, die komplette Klasse testen ohne irgendwas, ohne eine Socket zu bauen und ohne eine Datei zu behören auf die Festplatte, das macht man dann relativ einfach. Das ist, wenn wir eine Unix Anwendung nehmen, also wenn wir ein Unix Anwendung, wir sehen, dass die bleiben immer von den, sie gehen immer zu ein von den zwei ersten an Teste. Entweder ist das alles hard codiert oder die Speichensachen in einem hard codierte Ort auf die Festplatte oder einen bestimmten Ort, wo sie die Zugänge, also alle Unix Dateien, die wissen, dass das alles auf var run um einen Name Server zu bekommen und es gibt keine Möglichkeit, das zu überladen dieses Verhalten und das wird meistens in, also das wird ansonsten in eine Konfiguration Datei, die immer an der gleiche Stelle gesparsiert ist und also die müssen da gelassen werden, statt die reinzugeben und wir haben kein Netzwerk Sockets, also man muss die Konfiguration Datei, indem man welche IP Adresse zuhören soll und welcher Port es hören soll und das erlaubt nicht einen, die das Verhalten zu ändern, also retransmission, also weiter wiederversenden und so weiter, das muss dann an der Web Server gemacht werden, dass es dann in der Konfiguration Datei ist, hier ist ein extra Konfigurationsattribut und wo man das spezifiziert, diese Parameter und diese müssen dann verwendet werden, um die TCP-Socket zu erstellen. Der Web Server baut diesen ganzen, diesen ganzen Rattenschwanz an Konfigurationssachen, die eigentlich außerhalb der Server sein sollten, das brauchst du nicht, man drehen. Und ich glaube, das ist ein doppelter Standard. Wir brauchen bessere, wiederverwendbar und testbare Software haben und das ist zum Beispiel ein Beispiel von wiederverwendbar und testbare Software, ich möchte nicht zu viel Zeit darauf verlassen, starten TCP-Socket zu erstellen, es gibt, man kann davon ausgehen, dass das Standard in ISM TCP-Socket und man kann das starten, egal wie man will, also egal, ob es IPv4 oder IPv6, das funktioniert immer noch, es kann je gleichen Streaming-Protokoll verwenden, das ist egal, egal welcher Port, das ist, man kann sogar die Socket einmal erstellen und verschiedene Web Server erstellen, die alle die gleiche Sockets nutzen und dann hat man gleich verschiedene Liefen. Und man kann auch Unix Socket verwenden, um sehr einfach zu testen oder Kapttür zu machen. Das ist für mich einen deutlich besseren Modell, als was wir Unix sehen und jetzt habe ich erklärt, jetzt habe ich relativ lange erklärt, was ich denke, was falsch ist und jetzt möchte ich erklären, was CloudEbi ist. Also das ist, ich versuche das alles zu lösen, das ist eine neue Unix-Like-Umgebung, Laufzeit-Umgebung, denkt daran wie POSIX, der Unix-Standard plus andere Sachen, die von Capsicum gegeben werden, minus alles, das ein Konflikt hat mit Capsicum. Und das macht deutlich einfacher, ein Software zu schreiben, der mit Capsicum läuft. Wenn man die FU-Handarm schreiben, erst mal hochfahren und dann, wenn es jetzt nicht, wenn es nicht sauber ist, dann kompiliert es nicht. Das ist nervig, aber das ist deutlich einfacher, einen Kompilierungsproblem zu lösen, als einen Problem zu lösen, der von der Sicherheitsframework hergestellt wurde. Also wie ich vorhin erklärt habe, diese eine Sache mit der Sicherheitsproblem mit dem Öffnen der U-Handarm. Man merkt das einfach nicht. Das ist, also ich habe es selber so gefunden und wenn man diese Schnichtstelle schweckt macht und dann wird es ganz klar ist, wo das Problem in der Anwendung ist und das macht einen deutlich besseren Software zu laufen in einem Sandbox. Und wenn die Anwendung, können wir nicht mehr arbitrieren DCP Software oder irgendwelchen Dateien auf die Festplatte. Es gibt keine globale Namespace und das macht er sehr schwierig, irgendwas hart codieren. Die Anwendung muss testbar sein, es ist Pflicht dann. Es sollte nicht unbedingt immer so sein, weil es gibt ganz viele Software, der schon existiert, das auch weiterhin laufen soll, aber das ist schon eine gute Idee, wenn man für neue Software das zu forcieren. Und das ist ein Punkt, dass ich am Ende das Live machen möchte. Wenn ich diesen Talk halte, die Leute kommen und sagen, das ist schön, aber das würde nicht funktionieren für traditionelle Unix Verwendungsfall X. Nein, das weiß ich so. Es ist einfach eine grüne Wiese. Also okay, Cloud ABI kann machen bei default. Also das einfachste Cloud ABI Software, es kann nichts, es kann, es kann du APC mit sich selbst, es kann auch Spray starten, es kann mit dem Cloud, also es kann auch forken. Es kann mit den Uhr, es kann bestimmten Daten aus dem Körner bekommen. Also es ist kein Problem, wenn für ein kleinen Software ist es kein Problem. Also es gibt eigentlich kein Sicherheitsproblem mit die Uhrzeit zu bekommen, aber es kann keine Pfade auf die Festplatte, es kann keine Netzwerkverbindung erstellen und es kann auch keinen, nicht überprüfen, was andere Prozesse machen. Und wenn man Punkt slash Wasser himmer, es ist nicht in der Lage irgendwelchen Problemen zu erst, Sicherheitslücken zu nutzen auf dem System. Und dann möchte man dem Programm natürlich weitere Rechte geben, damit das weitere Funktionalitäten machen kann. Also als erstes muss man sicherstellen, dass das Programm mit den Standardberechtigungen zunächst mal gestartet wird. Das ist wichtig, denn man muss ja sicherstellen, dass man genau nur die Berechtigung hat, die man braucht. Okay, wenn man also jetzt zum Beispiel weitere Rechte hinzufügen möchte, macht man das über File-Deskriptoren. Und das ist eine, die meisten von euch sind wahrscheinlich, kennen wahrscheinlich das Change-Route-System, um ein anderes Routverzeichnis einem Programm vorzugageln und stellt euch das hier vor wie ein Change-Route auf Steroiden. Jede Berechtigung wird durch einen File-Deskriptor repräsentiert. Und Netzwerk, um damit das Programm auf Netzwerke zugreifen kann, wird natürlich Socket benutzt. Wenn man also ein Unix-Socket hat, also es funktioniert nicht für TCP-Sockets, aber ein lokaler Unix-Socket, kann es ein File-Deskriptor auf der einen Seite des Sockets einfach was reinschreiben und das sieht man dann auf der anderen Seite des Sockets wieder. Und damit kann man ein paar relativ komplexe Sachen machen. Ein Programm startet also und hat standardmäßig erst mal nicht sehr viele Rechte. Später kann man dann zum Beispiel Nachrichten an einen Prozess schicken und das Programm kann sagen, ich muss diese E-Mail an UserX schicken, bitte gib mir Berechtigung auf die Mailboxes UserX und dieses zentrale System gibt dann ein File-Deskriptor zurück, über das das Programm auf die Mailboxes Users schreiben kann. Also es ist eine sehr möchtige Sache. Und es unterstützt auch die sogenannten Prozess-Deskriptoren, ich habe das schon mal erwähnt, was Capsicum gemacht hat und CloudABI jetzt auch sind Prozess- Deskriptoren. Es gibt einen speziellen Vorkall und sobald man diesen aufruft, bekommt man ein File-Deskriptor zurück auf den Kindprozess. Und wenn man diesen File-Deskriptor dann schließt, dann wird der Kindprozess automatisch terminiert. Das heißt es gibt also keine Möglichkeit, dass man irgendwelche Ressourcen allokiert lässt. Und es ist auch sehr wichtig zu erwähnen, ich habe das auf einer letzten Konferenz, hat einer einen Kommentar gemacht, was ist denn, wenn man Prozess-Deskriptoren von Sockets passen könnte. Man könnte also zum Beispiel ein Prozess-Deskriptor erlauben, an den Child-Prozess weitergereicht zu werden und das könnte dann unertlich tief passieren. Und Prozess-Deskriptoren sind für Unix Sockets also nicht unterstützt. Das ist eine Einschränkung, die wir da machen. Die File-Deskriptoren haben auch diese üblichen Permission-Bitmasks, über die man also die Berechtigung einstellen kann. Man könnte also zum Beispiel ein File-Deskriptor für einen geteilten Speicherbereich einrichten. Und wenn man dann den File-Deskriptor dupliziert, kann man auf dem zweiten Deskriptor das Schreibe-Bit abschalten und das dann an einen weiteren Prozess geben. Und dieser Prozess können dann nur von dem geteilten Speicher lesen, aber nicht da reinschreiben. Das sind also solche Sachen, die man über diese Bitmasks machen kann. Um einen Web-Server jetzt sicher zu machen, es ist eigentlich ein Straight-forward-Prozess. Man ersetzt einfach den Socket durch einen File-Deskriptor, also wenn man zum Beispiel AF-1.6, einen TCP-Socket für die eingehenden HTTP Anfragen benutzt, kann man einen Read-Only-File-Deskriptor benutzen, auch für das Directory, in dem die Verzeichnisse für den Web-Server gespeichert sind. Und einen Angreifer kann demnach also nie die Dateien, die dort gespeichert sind, modifizieren. Und man kann dem Web-Server genauso gut auch einen Append-Only-Deskriptor geben für das Lockfall. Das heißt, das Einzige, was ein Angreifer machen kann, im schlimmsten Fall, ist, er kann euer Lockfall mit irgendwelchen Müll zuschreiben. Er kann keine vorhergehenden Einträge überschreiben, er kann nur Sachen hinten dranfügen. Als ich angefangen habe, damit ein bisschen zu spielen, habe ich gemerkt, dass Unix sehr, sehr klein wird, wenn man diese ganzen Legacy-Code wegnimmt. Und man wird auch ein bisschen inkompatibel mit dem alten Security-Modell. Cloud-EBI hat im Endeffekt nur 58 Systemaufrufe, das ist also wirklich sehr winzig, insbesondere wenn man das zum Beispiel mit Linux vergleicht. Ich glaube, Linux hat 300 und FreeBSD hat ungefähr 400. Das heißt, es ist auch nicht so übermäßig schwer zu implementieren. Das heißt, es ist auch sehr einfach, Unterstützung für Cloud-EBI zu existierenden Betriebssystemen hinzuzufügen. Ich habe also angefangen mit Cloud-EBI für FreeBSD. Und ich glaube, alles, was ich gebraucht habe, war ungefähr ein halbes Dutzend Zeilen Quellcode und damit ich es auf anderen Systemen ausführen konnte. Mein Ziel ist jetzt momentan, das auf Linux zu bringen. Linux braucht ein bisschen mehr Arbeit an der Stelle, denn man muss zum Beispiel mit diesem Multibinary-Interface auch zurechtkommen. Der Linux kann das nicht wirklich unterstützen. Ich muss da so ein paar ein paar Sachen hinzufügen. Ich habe aber nur wirklich ein paar Zeilen nativen Code zu dem Betriebssystem Kern selber hinzugefügt. Und danach kann man Binarys also ausführen, ohne sie neu zu kompellieren. Und das ist eigentlich eine schöne Sache, insbesondere im Bereich des Cloud-Computing. Zum Beispiel, wenn man einfach nur ein Host-Provider ist, dann laden die Leute einfach Binarys hoch. Und es ist also wirklich ein Killer-Feature, diese einfach ausführen zu können. Okay, kommen wir jetzt dazu, wie man Software für Cloud-ABI entwickeln kann. Als erstes Cross-Compile ist eigentlich eine ziemlich schwierige Sache. Typischerweise ist es nicht möglich, Out-of-the-Box einfach Software für Cloud-ABI zu kompilen. Es wäre natürlich schön, wenn das alles ginge, aber ich werde in den nächsten paar Slides erklären, warum das ein bisschen schwierig ist. Das Problem ist, dass die ganze Toolchain, um Cloud-ABI-Software zu kompilen, hängt von verschiedenen Komponenten ab. Zum Beispiel ein Compiler, ein Assembler, ein Linker. Es gibt eine Standard C und C++ Bibliothek, mathematische Bibliotheken und so weiter und so weiter. Es ist eine riesengroße Liste und man hat also wirklich nur das absolute Minimum davon, um Cloud-ABI-Software zu bauen. Das Ganze noch aufzusetzen, braucht auch eine ganze Ecke Zeit. Und man muss natürlich auch sehr viele Patches schreiben für alle Zusatzsoftware, die man noch benutzen will. Viele APIs wissen mit Cloud-ABI nichts anzufangen und die muss man deshalb rausnehmen und das führt dazu, dass der Bildprozess nicht mehr funktioniert. Viele der APIs, die man sonst benutzt, sind entweder veraltet oder machen im Zusammenhang mit Cloud-ABI nicht mehr übermäßig viel Sinn. Und was auch ein bisschen ärgerlich ist, ist Teile der Infrastruktur, wie zum Beispiel Autoconf, unterstützen, unterstützt hinten anfangs noch kein Cloud-ABI, mittlerweile tun sie es. Aber Versionen vor März 2015, wenn man da versucht, was für Cloud-ABI zu kompilen, dann hat man auf die Meldung bekommen, dieses Operating-System kenne ich nicht. Und deshalb habe ich angefangen, an einer Cloud-ABI-Ports-Collection zu arbeiten. Das ist im Grunde nur eine Sammlung von Bildscripts, die es euch ermöglichen. Jede Menge Open-Source-Bibliotheken zu bauen, dazu gehört unter anderem Boost, was für C++-Programmierer sehr interessant ist. Einige andere Bibliotheken für HTTP-Zugriff, Teile beispielsweise, für Desktop-Applikationen, es gibt verschiedene Crypto-Bibliotheken, Libre-SSL, und ich habe auch mit Skript-Sprachen wie zum Beispiel Lua angefangen. Mittlerweile arbeite ich am Python, das ist natürlich sehr viel interessanter als Lua für viele. Das Interessante ist, man baut diese Pakete einmal. Ich baue die auf meiner Linux Workstation und auf meinem FreeBSD-Server. Und daraus macht man dann einfach eine handvoll native Pakete für verschiedene Betriebssysteme. Man bekommt also zum Beispiel Debian-Packages daraus. Das heißt, als End-Ponuzzer ist das einzige, was man machen muss. Man muss einfach zu meiner Website gehen. Ich habe auch eine Ende von meinem Talken-Link zu dieser Website. Und da gibt es dann einfach ein paar Anleitungen, wie man zu seiner sources.list zum Beispiel einfach einen Repository hinzufügen kann. Und dann nimmt man einfach App-Get und holt sich diese Packages. Und die sind identisch quer über alle Betriebssysteme. Das ist also beid für beid der identische Code. Und das bedeutet, dass man eine sehr konsistente Entwicklungsumgebung davor kommt. Es ist völlig egal, ob man eine Applikation unter Linux oder BSD kompalt, theoretisch. In der Praxis gibt es auch noch der eine oder andere Probleme. Die Checksum der der Binär-Pakete sollten aber identisch sein. Das ist wirklich eine schöne Sache. Ich werde da jetzt nicht zu sehr ins Detail gehen, warum die Binär-Pakete noch nicht absolut identisch sind. Aber ich bin in der Lage, das zu erklären, wenn einer daran interessiert. Der Punkt ist, dass ich benutze keine der nativen Build Tools. Alles das wird auf meinen Linux und BSD Maschinen kompalt. Und das Ziel hier ist natürlich, dass letztendlich euer Betriebssystem natürlich die Nativ-Toolchain bereitstellen muss. Also wenn ihr ein Package-Mentainer seid, dann würde ich gerne mit euch reden, denn es wäre toll, wenn ich Cloud-ABI für mehr Betriebssysteme anbieten könnte. Hier eine richtig ganz kurze Erklärung, wie man diese Cross-Compiler-Toolchain auf FreeBSD installiert. Die Schritte unter FreeBSD sind ein bisschen einfacher als unter Linux. Und ich wollte, dass diese Folie schön einfach aussieht. Auf FreeBSD ist es so. Als erstes lässt man PKG-Instaurer Cloud-ABI-Toolchain aus. Und damit bekommt man dann die neuesten Version der Bin-Utils. Und diese Pakete werden von FreeBSD selbst bereit bestellt. Wenn man das gemacht hat, hat man den Compiler. Aber man kann leider noch nichts kompilen, weil noch keine Cloud-ABI-Bibliothek auf dem System existiert. Das heißt, wir brauchen noch einige weitere Sachen. Man kann zum Beispiel hier einfach, wie man hier auf der Folie sieht, Package-Update laufen lassen und dann diesen etwas länglichen Package-Install befehlen. Was man hier sieht, ist der Name der Architektur. Also x8664 Cloud-ABI. Und das Paket selber ist dann CXX Runtime. Und wenn man das macht, bekommt man eine C und C++ Bibliothek. Und das ist ausreichend, um die meisten C und C++-Programme zu kompilen. Und sobald das gemacht hat, kann man einfach den Cross-Compiler aufrufen, um jedes beliebige Stück Software inklusive Hello World für Cloud-ABI zu kompilen. Und jetzt, wo ich erklärt habe, wie man Cloud-ABI-Software entwickeln kann, werde ich erklären, wie man Cloud-ABI-Software startet. Es ist etwas interessanter, als man meint. Es gehört ein bisschen was dazu. Wenn wir uns mal eine sehr einfache Unix-Applikation anschauen, zum Beispiel LS. Die Leute benutzen die Applikation LS. Also brauchen wir wirklich erklären, was diese Applikation tut. Auf jeden Fall, was wir jetzt einfach machen, ist anstatt, dass wir einfach open von dem Verzeichnis Punkt aufrufen oder was auch immer. Das können wir hier nicht machen, denn die Applikation hat kein Arbeitsverzeichnis. Cloud-ABI gibt es dieses Konzept nicht. Deshalb rufen wir fd-open-dir auf und da kann man eben einen Falldescripter bekommen. Und auf diesem Falldescripter rufen wir dann fd-open auf, um alle Dateideskriptoren zu kriegen, die da drin sind. Wie ihr auch seht, gibt es kein std-out in dieser Laufzeitumgebung. Wir müssen einfach annehmen, dass std-out mit einem Falldeskripter, den wir haben, übereinstimmt. Und wie rufen wir das jetzt auf? Es ist etwas nicht so richtig traditionell. Wir compilen es, lassen es durch unseren Cross-Compile laufen. Dann laden wir einen Kernel-Modul, der auf FreeBSD benötigt wird. Das Schöne ist, in FreeBSD 11 ist das defaultmäßig schon integriert. Das heißt, wenn man einfach den letzten Development-Snapchat von FreeBSD sich runterlädt, dann funktionieren diese Cloud-ABI-Geschichte out of the box. Man muss also nichts weiter installieren, keine Packages weiter installieren, funktioniert einfach. Das ist eine tolle Sache. Wenn man dann das Binary hat, rufen wir einfach auf dot-slash-ls, aber wir müssen eben natürlich noch einen Falldescripter mitgeben. Nämlich das Directory, auf dem wir auf dot-slash-ls-flach-links-slash-etc und das funktioniert. Damit bekommt man ein Listing aller Dateien in etc. Also das ist so ähnlich wie eine Hello World-Applikation, mehr oder weniger. Und obwohl das funktioniert, ist das nicht wirklich so die Art und Weise, wie man Prozesse startet. Und das kann ein bisschen komplex werden. Wenn man einen Web-Server mit 20 verschiedenen Falldeskriptoren starten will, dann ist das keine schöne Sache, die Shell ist eigentlich nicht dafür gedacht, so was zu machen. Es ist ein sehr komportierbarer Weg, um zum Beispiel Netzwerksockets auf diese Art und Weise durch die Shell anzulegen. Woher weiß man, in welcher Reihenfolge die Falldeskriptoren vorliegen? Woher weiß mich, dass das Falldeskriptor Nummer 14 mein Socketdeskriptor ist? Vielleicht ist das was ganz anderes. Also das wird sehr komplex. Also bitte benutzt das nicht auf diese Art und Weise. Das wird wirklich unübersichtlich. Und man verliert auch dieses existierende Thema, wo man für eine komplette Applikation nur noch eine einzige Konfigurationsdatei braucht. Bisher war es immer so, man kann in ATC irgendwas ändern, startet die Applikation neu und es funktioniert. Wenn man es einfach aus einer Shell ausführt, dann braucht man ein separates Konfigurationsdatei mit Attributen. Aber dann muss man den Web-Server mit all diesen verschiedenen Falldeskriptoren starten. Also wenn man das so, man hat also zwei verschiedene Art und Weise die Applikation zu konfigurieren. Die Applikation ist auf der einen Seite und die Falldeskriptoren auf der anderen Seite. Und ich wollte diesen Prozess ein bisschen einfacher machen und sicherer machen und auch ein bisschen vernünftiger machen. Und da kam ich auf ein Launcher-Tool. Das nennt sich CloudABI-Run. Das sind eigentlich nur 100 oder 200 Zeilen C-Code, also relativ klein. Und was dieses Tool macht, ist ersetzt die traditionellen Command Line Argumente, was einfach nur Strings sind, durch eine Baumartige Struktur, die seemantisch so ähnlich wie Jamel aussieht. Und ich werde in den nächsten paar Slides erklären, wie das aussieht. Und dann werde ich erklären, wie das funktioniert. Also wenn wir annehmen, dass wir einen traditionellen Unix-Prozess haben, also keinen CloudABI-Prozess. Und dann haben wir ungefähr so eine Konfigurationsdatei. Also wir haben zum Beispiel ein Schema, was ungefähr so aussieht. Wir haben einen Hostnamen. Wir haben dann irgendwie eine Log-File. Wir haben ein Thread-Pool und wir haben eine Anzahl von Connections vor. Wir geben eine IP-Adresse vor, die der Web-Server lauschen soll. Und so weiter. Mit CloudABI-Run würde dann diese Datei mit Annotations versehen. Das heißt, anstatt, dass man einfach diese Fahrtnamen direkt angibt, wie in diesem Beispiel hier, oder die IP-Adressen direkt angibt, benutzen wir einen speziellen Tag. Ich habe eine Anzahl von Pipes hier erzeugt. Und man kann damit angeben, welche Strings Fahrtnamen sind und welche Strings IP-Adressen sind, mit denen sich das Programm verbinden soll. Und das Programm passt dann. Diese Datei scannt diese Interregion der Datei, sieht die Socket- und Filtax und ersetzt die durch den Fall des Skriptor. In diesem Fall die Verzeichnisse und die Netzwerksockets. Und am Ende bekommen wir dann etwas raus, was ungefähr so aussieht, so wie so eine Art Präprozessor. Und das ist das, was die Applikation dann bekommt. Wenn ihr also ein Programm schreibt, gibt es also anstatt der Main-Methode jetzt eine Methode, die heißt Program-Main. Und da gibt es also einen Arc-Data-Header. Und man muss also durch diese Datenstruktur durchlaufen und muss die Informationen, die man benötigt, sich da raus extrahieren. Und bekommt dann zum Beispiel über diese Get-Stringen und Get-Bullien die ganzen Einträge raus. Und kann da auch diese Art Maps und andere Sachen rauskriegen. Also alles, was in dieser Yaml-Datei spezifiziert ist. Und das ist eigentlich in meiner Meinung nach ein relativ netter Kompromiss, denn es ist vielleicht, es ist nicht wirklich schwieriger, als es jetzt ist, man hat immer noch eine einzige Konfigurationsdatei, wo man die Attribute festlegt, aber auch die Ressourcenabhängigkeiten festlegt. Und außerdem macht es auf diese Art Weise unmöglich die Reihenfolge falsch hinzuschreiben. Und außerdem hat man, stellt es auch sicher, dass diese Dateideskriptoren, die in dieser Datei nicht spezifiziert sind, dass die ja auch am Ende geschlossen sind. Und für Softwareentwickler heißt es, dass man nicht mehr ein Konfigurationsdateiparser schreiben muss, sondern man kann einfach durch diese Struktur durchgehen, um die Konfigurationsparameter sich zu holen. Und man braucht auch keinen Code mehr zu schreiben, um die Ressourcen beim Programmstall selbst zu akquirieren. Und das ist eine schöne Sache. Das heißt, sobald das Programm losläuft, kann man sofort anfangen zu arbeiten, anstatt hunderte oder tausende Stellen zu haben, um die Konfigurationsdateiparsen und die Ressourcen zu allokieren. Wir gehen mal schnell in die letzten Minuten. Ich würde erst einmal ein paar Anwendungsfälle zu erklären. Ich glaube, ihr könnt auch weitere Usegases finden. Bei einem von meinem vorigen Job habe ich auf einen Gerät für Netzwerksicherheit. Das war ein Spam-Filter. Ich kenne nicht mal der Name der Firma. Immer nicht mehr. Aber das war ein Unix-Prozess, der auf diesen Gerät, diesen binären Blob und es war als Cloud-EBI. E-Mail wurden auf ein Pipe geschickt und dann die Anwendung schickt zurück, ob es ein Buffer overflow in diesem Spam-Filter gibt. E-Mail. Es gibt überhaupt keinen Einfluss. Es kann nicht mehr extra CPU nutzen. Aber es kann nicht mehr so viel. Vielleicht einen falschen Kinespam, obwohl es welche war. Es ist besser als Root werden auf dem Hardware. Das gleiche für Netzwerkeräte. Es gibt Möglichkeiten, Paket-Filtering im User Space, zum Beispiel Netmap, wo man Netzwerkpakete im User Space bekommen und die Logik im User Space implementiert wird. Es kann auch als Cloud-EBI implementiert werden, also 100% mit einer Klustermenagement. Die Abhängigkeiten sind bekannt. Die Ressourcen aus dem Programm zu bekommen werden von außen gebracht. Für ein Cluster ist es auch ziemlich nett. Man hat ein paar Webfrontent-Anwendungen, ein paar Backends, ein paar Badjobs und diese haben alle Abhängigkeiten, die in einem Graph erklärt werden werden können und mit diesem Graf kann man die reichige Reihenfolge starten und die eine werden in einen, also die Backend werden in Japan gestartet und in Deutschland werden Frontend. Man kann die Lokalität, wenn man das alles von vornherein weist. Also es macht die Migration vom Prozess ein bisschen einfacher, weil man ganz genau, worauf der Prozess sich verlässt. Und das ist wirklich sehr weit in der Zukunft, ob es überhaupt passieren wird oder nicht, aber ich mag diesen Traum haben. Also es gibt diesen, es gibt einmal so ein Isidu, das ist ein Dienst und das finde ich sehr schön. Man kann arbiträren Unix-Programme in der Cloud starten, egal welchen Programmiersprache sie gespricht sind. Man kann VMM herstellen und man kann dann, wir können da wirklich irgendwelchen Sachen starten. Es gibt auch Google App Engine, das muss entweder Java, Python oder Go und die starten das für dich und das ist ja dann hoch skalierbar. Also die skalieren das. Wenn das System runtergeht, dann wird es woanders gestartet. Also das ist ja managed und Cloud API könnte verwendet werden, um beide zusammen zu führen. Also ein Manage-System, wo man sich nicht wirklich um einen Linux oder Windows-System kümmert, aber trotzdem meine Niederlage ist, in jeglichen Programmiersprachen zu entwickeln, wie man das man möchte. So, das ist alles, was ich zu sagen habe für heute und wir haben überhaupt kein Zeit mehr, glaube ich. Ich habe noch ein paar Links, die da sind. Der erste Link ist ein Link zu meiner Consulting Company. Es gibt auch Dokumentationen, wie man das nutzt. Es ist alles Open Source. Da unten habt ihr der Link zu meinem GitHub Page, so die von meinem Firma. Oben ist der C-Library und unten ist ein Package-Sammlung. Und wenn ihr irgendwas sieht, was ihr möcht, dann, ja, ihr könnt auch mir sehr gerne Pull Request schicken. Ansonsten gibt es einen Erk-Channel auf Fnet. Wenn ihr lurken möcht, bitte schön. Und das ist alles, was ich zu sagen habe. Vielen Dank fürs Zuhören. Thank you very much, Jack. If you have questions, please line up behind the four microphones we have here. Are there questions? Es gibt das Fragen von Erik. Keine Fragen vom Erik. Also, Mikrofon, vorne Links. Thank you for your talk. Vielen Dank fürs Talk. Ein der Probleme, das du da gestellt hast, ist, dass viele Prämitiven, dass wir nutzen, dass wir nutzen, in C-Libraries, dass du abhängig bist auf einem globalen Systemstatus, wie zum Beispiel Local Time oder irgendwelchen.conf, kannst du bitte wiederholen. Wie löst du das Problem von der Abhängigkeit von der globalen Status des Systems in C? Also zum Beispiel der lokalen Zeit. Ja, ist eine sehr gute Frage. Also als allererstes mal, ich bin mir schon klar, dass Systeme immer einen globalen Zustand haben. Und wenn man versucht, das zu eliminieren, das wäre viel zu optimistisch. Aber wenn man ganz unten anfängt, wenn man sich anguckt, welche Prämitiven den Strukturen von dem Betriebssystem bereitgestellt werden, da sollte kein globaler Status existieren. Wenn man also eine Umgebung hat, in der es einen globalen Zustand gibt, also beispielsweise, wenn es eine Workstation gibt, die eine Lock-in Session hat und die hat eine Menüzeile usw., dann kann man das eigentlich in den User Space verschieben, anstatt das über die Kernbibliotheken des Betriebssystems bereitzustellen. Leider sind Applikationen von einem globalen Zustand abhängig und ich sage nicht, dass wir es eliminieren können, aber es sollte einfach nicht Teil der Kernbibliotheken sein. Wenn du entwickelst mit Cloud API Anwendung, wie kriegst du den lokalen Zeit? Musst du der lokalen Timer reingeben als Falldestrektor? Ja, z.B. in dem Fall, dass der Konfigurationsteil für die Applikation, z.B. ein Eintrag, Zeitzone ist gleich Amsterdam oder was immer hat, dann kannst du innerhalb der Applikation dann diese Zeitzone benutzen, anstatt irgendeine globale Zeitzone aus ITC benutzen. Wir kommen von vorne, von rechts. Hi, kannst du mich hören? Du hast gesagt, du startest mit auf eine grüne Wiese. Das war nur ein Teil. Cherry OS ist ein Cambridge-Universitäts-Betriebssystem, wo man bestimmten, also es hat auch Kapazität und einen Custom OS und einem Custom Sprache und jedes Mal, dass ein Objekt instanziert wird, wird es nicht mit Daten, sondern auch mit einem Autorität verbunden, um auf Ressourcen zu agieren. Und das erlau, es ergibt also eine deutlich kleinere Angriffsfläche. Das ist, also das hier ist ca. die Hälfte der halbe Weg dort, also ein bisschen Kapazität, aber nicht die komplette Sache. Ja, es ist genial, dass du das ansprichst. Ich kenne die Leute, die da dran arbeiten, ziemlich gut. Ich plaudere alle paar Wochen mit denen und chatte mit denen. Ja, was diese Leute machen, ist sie bauen einen Prozessor, der solche Kapabilitätsregiste hat, also anstatt dass das auf der Betriebssystemebene passiert, wo es Dateideskriptoren und ähnliche Skriptoren gibt, kann man sagen, ich habe hier ein kleines Stück Speicher, zum Beispiel ein Buffer, in den die Applikation reinschreiben kann. Und wenn wir jetzt aber das Schreib-Bit wegnehmen und das einen anderen Thread geben, es wäre toll, wenn Cherry und Cloud ABI einen Kind zusammen hätten. Das wäre das tollste, was passieren könnte. Das ist eine coole Sache, denn vielleicht kennst du Brooks Davis, der ist auch ein FreeBSD Entwickler? Ich arbeite auf Thaulabs, das ist ein kryptografischer Kapabilitätssystem und wir haben eine unterschiedliche Sicherheitssysteme. Du sagst, dass Cloud ABI damit Kinder machen sollte. Ja, möglicherweise. Wir müssen danach sprechen. Ich wollte nochmal kurz das Erwähnen aus meiner Perspektive. Ja, es ist toll, dass du das ansprichst. Schaut euch an, Cherry wird auch von der University of Cambridge entwickelt. Tolles Projekt, cool. Also, nächste Frage zuerst, vorne links, dann hinten links. Die Frage wegen Zeit, also eher eine Bemerkung. Ich kenne nicht deinen System, aber die Möglichkeit zu geben, die Zeit zu lesen, kann ein Gefahr sein, weil Uhren sind ein Unik und damit kann man die Maschine erkennen. Ja, das ist auch eine ziemlich gute Anmerkung. Berühmte letzte Worte. Selbst Cloud ABI ist nicht perfekt, also zum Beispiel die Tatsache, dass man auf die Uhr zu greifen kann an der Stelle. Das Ding ist, POSIX hat bereits ein schöner standardisiertes Interface, um zum Beispiel mit Verzeichnissen und Fileskeptoren umzugehen. Und Sachen, die ich, ich habe das nicht in den Slides erwähnt, aber Teile, die ich benutze, sind von 2008 in der POSIX Standard und ich muss immer darüber überlegen, wie kann ich Leute dazu bringen, das zu nutzen und zum Beispiel jetzt die Clock API ist zum Beispiel eine Möglichkeit, wo ich sagen kann, ich will eine falsche Uhrzeit der Applikation mitgeben. Wir haben jetzt zum Beispiel 2015, aber ich könnte zum Beispiel Applikation sagen, es ist ein ganz anderes Datum, damit können die auch zum Beispiel gut Tests machen oder Compliance Bucks finden. Es gibt halt keine, keine API dafür. Und ich wollte halt, dass die, dass es sehr viel einfacher wird, für die Leute Cloud ABI zu nutzen und ihnen nicht so viel Kopfschmerzen bereitet. Und leider gibt es halt keine Möglichkeit da irgendwelche x-beliebigen Zufallsgeneratoren oder Uhrzeiten rein zu initiieren. Hinter den Mikrofonen bitte, links. Okay, okay. Wie funktioniert diesen Kapabilitätsbasiertesystem mit RPC, insbesondere wenn es kein Eltern-Kind-Beziehung gibt? Kannst du bitte wiederholen. Also wie funktioniert die Kapabilitätsmodell, spielt mit, mit Prozesskommunikationen, insbesondere wenn es kein Eltern-Kind-Kind gibt? Ja, jetzt müsste ich eigentlich eine ganze Liste rausholen mit den ganzen Anforderungen oder Spezifikationen, was ein kapabilitätsbasiertes Sicherheitsmodell überhaupt ist. Es gibt einen Weg, wenn meine Interpretation eines kapabilitätsbasierten Sicherheitssystems korrekt ist, dann hat sozusagen jedes Programm einen ganzen Sack von Tokens und diese Tokens repräsentieren die Kapabilitäts, z.B. Falldeskriptoren. Und jeder Prozess kann mit diesen Falldeskriptoren eine Reihe von Sachen machen. Es kann z.B. sie einfach wegwerfen. Es kann sie aber auch an andere Prozesse weitergeben und es mag vielleicht auch andere Anforderungen geben und Eigenschaften. Aber ist das eben kein kapabilitätsbasiertes System? Was fehlt dir daran? Also es gibt Möglichkeiten, die Sicherheit von einem Interprozess. Ja, ich glaube, du beziehst dich auf die Tatsache, dass es da noch diese Sache gibt. Es könnte möglich sein, Tokens von anderen Prozessen zu klauen und kann ich also irgendwie sagen, ich möchte dieses Programm daran hindern, etwas X zu zugreifen. Man startet also ein Prozess und man gibt eben diese Tokens, aber es gibt keine Möglichkeit es später wieder wegzunehmen. Das fehlt so ein bisschen dieser Umgebung. Aber wenn man den Prozess gleich mit dem richtigen Menge an Berechtigungen startet, dann ist man, denke ich, auf der sicheren Seite. So, wir haben eine Frage vom Erk, Signalengel. Wie ist es unterschiedlich von Docker, der auch sämtlich Change Routes mit Steroids? Wie ist dieses Berechtigungsmanagement unterschiedlich von Docker, der auch CH Routes auf Steroid? Ich muss gestehen, es gibt sehr viele verschiedene Betriebssysteme da draußen, die alle auf eine verschiedene Anweise diese Capability basierte Sicherheitssysteme machen. Ich glaube, was Cloud ABI einzigartig macht, ist zum einen das basierte der POSIX API, für die es bereits ein Haufen existierender Software gibt. Und wenn man es vergleichen mit Capsicum, es hat den Vorteil, dass man sich nicht so leicht in den Fuß schießen kann. Es mag andere Systeme geben, wo sich die Funktionalität zum größten Teilen überlappt. Aber das ganze POSIX-Geschichten zum Laufen zu bringen, das ist eigentlich dieser Nischenmarkt in diesem Fall. Frage von vorne rechts, links. Also die meisten Sachen, die man mit Namespace machen würden, mit Usernamespaces, Netzwerknets, Namespace oder Mountbind, wie Docker das tut. Also Docker nutzt nur Username, die demnächst kommen. Seit Jahren ist es ein Kernelhack, um Usernamespaces in der Kernel einzuführen, ist 150 Stücke zu berühren und jemanden entwickelt. Ein Entwickler arbeitet dran, aber das ist noch nicht fertig. Aber wenn ich eine kritische Anwendung habe, möchte ich das mit einem anderen User und möchte seine Rechte wegnehmen. Und das ist relativ ähnlich zu diesen Docker-artige Container-Bauen-Dinks. Und es gibt dann ganz viele Sachen, die ich nicht anpassen muss. Also du hast mit Java gesagt, gib mir einen Java-Binäern, der seine File-Deskiptoren nicht kennt. Ja, ich glaube, das ist so wie, da gibt es so eine Trennung, wenn man so will. Und die Leute stehen auf zwei verschiedenen Seiten. Zum einen gibt es den Fokus darauf, dass man auf dieses Capability-basierten Systeme umsteigt, aber auf der anderen Seite gibt es auch eine Bewegung in Richtung Virtualisierung von Namespaces. Und da ist zum Beispiel auch FreeBSD-Jails mit integriert und Docker auch. Und bei einem Problem damit mit dem ganzen Namespace-Konzept in Linux und den ganzen anderen Systemen ist, es nimmt ein Stück Transparent weg. User-IDs, User-Credential-Namespacing, das kann ziemlich nervig werden, wenn man zum Beispiel PS ausführt auf einem System und man sieht die Prozesse uns einen Users und dann lässt man PS in dem einen Container laufen und auf einmal kommt dann eine andere Anzahl raus. Also es nimmt einem so ein bisschen Transparenz weg. Das schlimmste, was man machen kann, ist Bitname-Virtualisation. Das braucht man eigentlich nicht. Zum Beispiel, wenn man, wenn man Bit75 in einer Umgebung ist, vielleicht eine ganz andere Bit in einer anderen Umgebung und das ist so eine der Gründe, warum dieses System versucht ist, auf eine Weise zu lösen, dass man Sachen wegnehmen, anstatt einfach weitere Sachen hinzuzufügen, um das Ganze ein bisschen sicherer zu machen. Es gibt so diese starke Meinung aus irgendeinem Grund, dass es keinen Weg gibt, warum wir niemals eine einzige Applikation auch nur im Userspace verändern könnten. Und ich glaube, die Zeiten ändern sich. Unix ist mittlerweile schon 40 oder sogar 45 Jahre alt. Warum kann es sich nicht mehr verändern? Das ist das, wo ich mit experimentiere. Aber es ist eine... Aber ich hoffe, dass ich glaube, du wirst das ändern. Und wenn du das Ganze im System D einpackst, dann brauchst du nur dein System D sauber konfigurieren. Und dann, viele Leute mögen System D nicht. Ja, es ist eine andere Lösung, dieses Problem zu lösen, indem man halt noch mehr Sachen in dem Kernel hinzufügt und mehr und mehr und mehr Virtualisierung und Namespaces und Features in den Kernel hinzufügt, um dieses Problem zu umgehen. Oder aber indem wir einfach sagen, wir nehmen Sachen aus dem Userspace weg, das sind halt diese zwei verschiedenen Ansätze. Und wir haben eine weitere Frage. Was bedeutet für Skripting Sprachen in Shell? Wenn ich ein schnelles Shell-Skript zusammenmacht, muss ich irgendwie rumspummeln mit der Kapazitäten oder muss ich erzut? Und dann kann ich alles und verliere die Vorteile? Unix Shell ist etwas, was wirklich orthogonal zu dem, was ich entwickelt steht. Es würde mich überraschen, wenn man jemals zu dem Punkt kommt, wo man zum Beispiel eine Born Shell hat und das würde mit Cloud ABI-Programmen gut funktionieren. Für Skriptsprachen glaube ich, ist es ein bisschen anders. Ich arbeite gerade daran, Python kompatibel zu machen und dann kann man einfach die ganzen Standard Python-Skript zusammenlaufen lassen, solange die nicht einfach versuchen, beliebliche Dateien von Platte zu öffnen. Und Python hat schon sehr schöne Interfaces in der neuesten Version mit solchen Sachen umzugehen. Und es wird eine Reihe Sachen kaputt machen. Und das ist auch der Grund, warum ich sage, dass wir eine Symbiose haben müssen. Es sind wirklich zwei getrennte Umgebungen und wir werden sehen, wo die Reise hingeht. So, vielen herzlichen Dank. Ed Colton. Ja, ihr habt die Übersetzung des Vortrags Cloud ABI.