 So hello, everyone. Next up, we have Ed Schouten. And he will be talking about Cloud ABI. Enjoy the talk. So hi there. Good afternoon. So my name's Ed Schouten. I'm an open source enthusiast from the Netherlands. And today, I'm going to talk about how I've been spending my time for the last two, two and a half years. So first, I'll give a short bio of who I am. I started using open source software back in 2003. That was the year I started studying in Eindhoven. And there was a Unix users group at my university. And the Unix users group was the only place where they had free Wi-Fi back then. So that was sort of a reason for me to become a member of the Unix users group. But soon, I discovered that the free Wi-Fi wasn't everything, and I actually became interested in all of the hardware that they had on display over there. So that sort of got me dragging to hacking on open source software. So what's actually pretty awesome is back in 2004, so that was the first year of my studies, I actually attended FOSDEM. And I counted around a bit. And I realized that this is the 12th time I'm actually attending FOSDEM. So still, the conference is all the same. They still have the same stickbreads as they had 12 years ago. So yeah, it's a pretty nice conference. So after hacking on open source software for a couple of years, I started using FreeBSD as my primary operating system on my systems. And I became really interested in how it worked under the hood, you know, vimming all of the source code that was stored under user source. Together with a guy from my studies, we actually even ported FreeBSD over to the Xbox One at one point in time, which was a pretty fun project. So in 2008, after sending in enough batches, filling up the bug tracker to FreeBSD often enough, I was awarded with a SVN account back then, or CVS even still. One of the first BSD conferences I attended was BSDCAN 2008 in Canada. And one of the speakers back then at the conference was Chris Latner. And maybe you've heard that, name in the news last week or two weeks ago, he's actually one of the founders of the LVM project. And now he sees some kind of compiler tech lead at Tesla, I think. And he gave a really good talk about LVM Clang, the CC++ compiler. So that really got me motivated on taking a look at that compiler as well. So one of the larger things I'd been working on back then was sort of integrating LVM Clang into the FreeBSD operating system, which is sort of the facto standard compiler today, at least in FreeBSD. So enough about FreeBSD and LVM, I'm not really going to talk a lot about those projects today. I'm actually going to talk about what I've been up to since 2014. And this talk is sort of a bit chronologically structured. So the first thing we're going to look at is what have I been doing in 2014? So back in 2014, I was working as an expat in Germany. I had some time to kill in the evenings. So what I started doing was I created a Git repo in my home directory and started hacking on some C++ code. I started working on a database server written in C++. And this database server was sort of making use of a whole bunch of things I'd never used before. So I was experimenting with data structures like Merkle trees for making sure that all of the data was consistent stored inside of it. What was really interesting about this database server that I was designing was that I wasn't using SQL queries or something to get access to the data. But I was actually loading a full Dart VM in there. So Dart is the scripting language that is being designed by Google, sort of a JavaScript replacement. And I thought that would be pretty awesome to actually design stored procedures in a high-level programming language like Dart. For replicating transactions across a network, I was using something similar to back source called Raft. But the problem with this project is I was only working on this a couple of evenings at night. The other evenings of the week, I usually went over to pubs together with some people sitting here in the audience even. So that project didn't actually make a lot of progress. In the end, it was just a forgotten Git repo that stayed on my home directory. And it might even be the case that I reinstalled my laptop so the code is now gone. But it was a really good excuse for me to experiment with all sorts of new technology that I hadn't used before. So just to give you a short overview of how it worked, you had a couple of servers that were connected with each other in a mesh. And that would just replicate all the transactions over that would be coming in. And then on the outside, you'd have a swarm of clients and maybe even some caching nodes that would hold on to certain parts of the tree and would make sure that that would all get replicated. So one of the things I was experimenting with with this database server was I wanted to harden it. So the problem is, you're running arbitrary Dart code in a virtual machine. What could possibly go wrong? It's a user-supplied Dart code. What if this Dart code simply contains statements in there that simply say, open these arbitrary files on disk, remove slash EDC slash password, et cetera? So I wanted to make use of sandboxing to actually make sure that even if there would be an exploit in a Dart VM, there would be no way of breaking out of the VM and running arbitrary code. The usage access pattern is quite simple. It either accesses its data set that the store does some kind of directory on disk. It talks to the other servers in the raft consensus group, so the inner mesh. And then you'd have TCP connections coming in from clients on the outside of the network. So what I did back then was I sort of got distracted. And instead of focusing on getting the database server working, I ended up focusing only on the sandboxing and getting that right, which meant that in the end I didn't have a functional database server, sort of completely stupid idea. So I sort of started making an inventory of all the security frameworks that are out there. And I sort of came up with this slide, sort of my observation of the current state of security frameworks. I'm by no means an expert on them, but this is sort of my interpretation of them. So at the top, they can be sort of divided in two separate groups. One's that I sort of call static policy-like, and other ones that I call dynamic capability-like. And they have a completely different mindset of attacking the problem of hardening software. So the static policy-like frameworks, they're sort of built from this mindset, saying the problem with unique security is in its security model, namely in the way file system permissions work. So we need to extend on that. File system permissions need to be more complex. There need to be more access control lists on more frameworks provided by the kernel. And good examples of those frameworks are App Armor and SE Linux and something that they call POSIX capabilities, even though that system has nothing to do with capability-based security. And those systems, they're typically configured by administrators, users, in some cases even package maintainers of operating systems. So App Armor security policies, they're typically written by distro package maintainers. They build what they do is they sort of run the program that they want to harden for a certain period of time. And they sort of analyze it for, say, a couple of hours, couple of days. And the output of that analysis is sort of turned into a security policy that's put in place. So what happens if there's some kind of exploit in it and then that attacker takes over the application? That person can only run the actions that are part of the security policy that was generated during the training phase. So what I've observed is that those security frameworks that I typically only provide very little gain in security. So the best examples I can give you, for example, a web browser has a file-open-file-save dialogue. Whenever you download a file and press Control-S, you get this pop-up box where you can browse the entire file system. Well, that sort of automatically means that this browser needs to be able to access the entire file system of your system. So it basically makes it pretty much useless. Also what I really dislike about the system is that it's configured by users and administrators, people who have no sort of real deep understanding of how the software works internally. And we sort of expect those people to come up with security policies to make the software secure. The software developer doesn't even care about it, sort of throws the code over the fence. And then other people have to clean up afterwards and make it more secure. So what you also see over the last couple of years is that all these new security models tend to pop up. And those are more dynamic capability-like. So how it works is that it's not a policy that's installed globally or in the system in slash EDC, but it's part of the programming APIs where the program can say, like, I've acquired all the things that I need to access. I've got my network connections. I can access these paths on disk. Now lock me up and throw away the keys. That's sort of how the security model works. And Linux has its second model. I think the most commonly used flavor of second is second BPF, where they have some kind of JavaScript stereo and an OpenBSD pledge. And these tend to have a really big gain in security, as you'll see in a couple of minutes. So a lot of people ask me whenever I sort of talk about this topic is, where does Docker fit in in this picture? And it's sort of a really tough question. But if you sort of look at how Docker is used typically, I'd say it's more like a static system. It's set up by the users to run a program in a confined space. It's not used as sort of an API by programs itself. So now we're sort of going to discuss how Capsicum works. And basically, Capsicum is a sort of two-step recipe for making software more secure. So the first thing that the Capsicum developers have sort of done is they've made the operating system sort of more object-oriented. You could call it like that. So what they've done is they've sort of turned everything into a file descriptor. So normally there are sort of multiple namespaces that the process can access. It has its file descriptors. It can access the entire file system namespace. Then there's the process table. Then there's the network stack. All sorts of separate frameworks. But what they first did is they sort of tried to unify it into a single scope, file descriptors in this case. So one thing that they've sort of really focused on a lot is having directory file descriptor support so that you can open a certain directory that's on disk and then sort of say like this file descriptor now represents all of the files that are stored underneath this directory. So you can point to subtrees in the file system basically. And what they've also done is they've added something called process descriptors, where instead of process IDs that are sort of global, system-wide, and you can send signals to them based on some very rudimentary form of access controls, they've changed that into process descriptors. So as you'll see later on, there's sort of a special fork call, PD fork. And that sort of gives you a file descriptor to a child process. And that you can't read or write over it, but it sort of acts as a handle giving you ownership of that process on the other side. And if you close it, you sort of lose that process. And in practice, that means that that process gets killed and shut down. So the second step that they've sort of done with Gapsicum is sort of now that the operating system is more object oriented, let's actually let those objects determine what the process can do. So a process can actually give uprights. It can say, I never need to access a certain resource anymore. I simply call it close on the file descriptor, and it's gone. Privilege separation. So say if you have this huge program and you want to divide it into multiple sub-processes that all have their sort of separate rights, that's called privilege separation. That's something that you can really easily implement by this model. You can simply fork the process into two processes. One process closes one half of the file descriptor, and the other one closes the other half. And then you've really separated the privileges of the process. Another very nifty feature of Unix-based operating systems that a lot of people are unaware of is that you can actually pass file descriptors to other processes. So if you create a unique socket between two processes, you can use a special message type called SCM rights, where you basically say, I've got this array of file descriptors. Now push it through the socket and pop it up on the other side. And if the other side receives those file descriptors, it sort of duplicates them into a different process. So that's also a really nifty trick where you can sort of say, I've got access to this directory, and now I need this other running process to write some stuff into it. Well, just push it through socket, and it comes out on the other side. And what you see is a result of this model is that Unix user group credentials, they become less important. So if you're using Capsucum, even if you run a process as root, it doesn't really matter anymore, because the rights that the process has are largely now determined by the set of file descriptors that it owns. So how does Capsucum work in practice? First of all, a process starts up like your ordinary Unix process. You can just run it from the command line or from an init script. At some point in time, the process calls the cap enter system call, and that sort of locks up the process. It switches the process over into something called capabilities mode. And when you do that, a lot of things are suddenly forbidden. So you can no longer open files by arbitrary file names. You can no longer bind to arbitrary IP addresses and port numbers. You can no longer connect to arbitrary hosts in the network. Also, regular forking is not supported because that needs to be done through the PD4 call. The same with killing processes. You can't just send arbitrary signals to processes in the process table. And the same holds for some administrative system calls. So rebooting and mounting doesn't make any sense, of course, if you're in this unprivileged mode. But there's a whole bunch of things that you can still use. So reading on file descriptors, writing on file descriptors, creating pipes and socket pairs, those are only things that sort of have this local impact. It doesn't have a global impact on the system. Then you can still use the open app system call, which was added in POSIX 2008, which is sort of a special flavor of the normal open system call, but allows you to open files underneath a certain directory. And same holds for connecting and binding to sockets. They've made special system calls where you can at least say, I want to bind a unique socket to a certain path under a certain directory. A very important aspect of capabilities mode, of course, is that there's no way of leaving capabilities mode. There's no cap leave system call. Otherwise, the entire security model would be useless, of course, because an attacker could take over an application, call cap leave, and then it could just go on as it normally does. So that's a really important aspect. So for my database server, how you use capsicum in this case is, again, the same strategy. The process starts up like a regular Unix process. It reads in its configuration file. And in the configuration file, it specifies which directories need to be used and which IP addresses on which we need to listen. So we create all these sockets and file descriptors. And then at some point, we call cap enter. And voila, from that point on, we can only start processing requests that are coming in. And we can't do anything else. So for my database server, I started using capsicum. And even though in theory, it sounds like a pretty awesome security framework that gives you some really tight isolation, I noticed that using it in practice can be pretty tricky. So it took me quite a long time before I managed to get the Dart VM working within capsicum. That was really exciting. So the reason for this is that you end up with all these pieces of code that are here on this slide. And they're used in practice. And they're simply there. And you'll sort of have to deal with that. So the top one was somewhere in the Dart VM, I think, to add some code in there where you could deal with times in different time zones. And if you sort of look and see how you convert times to a certain time in a time zone, you have to use the following sequence. So first, you change an environment variable called tz. You set it to the name of the time zone you want to use. And then what you do is you call this magic function called tz set. And this sort of reinitializes the C library to use a different time zone. And then afterwards, you can call the local time function. So under the hood, what happens, the tz set function tries to open files under user share zone info. But if you're calling cap enter, then that kind of code no longer works. And what's really annoying is that with tz set, you can't do any error handling. So this piece of code, it still works as it does normally. The only difference is that it still either represents a time in the old time zone that was sort of active before calling tz set, or it uses UTC or something weird. You can't really tell anymore what it does. And also this piece of code that was at the bottom was also fairly annoying. There is a piece of code that tried to convert a multibyte string to a white character string. So what does it mean in layman's terms? It took a UTF-8 string, and it converts it over to Unicode code points. So you can process it character by character. It uses this new locale function that sort of creates a handle to a localization object. And in this case, it's sort of representing UTF-8. The problem with this function is that it tries to open user share locale UTF-8 slash LCC type, or some file on disk. And it can no longer access it. So this piece of code sort of expects that it can sanely convert UTF-8 over to Unicode, but then it sort of starts to fail. And this piece of code is actually sort of the most interesting one I ran into, and this sort of really demonstrates one of the weaknesses of Capsicum. This is a crypto library. You can find it on the internet, liptoncrypt. You can find it on GitHub. Put the name of the source file in there. I've reported this issue numerous times to the upstream offer, but he doesn't respond. What happens? This piece of code tries to implement a cryptographically secure random number generator. So it tries to open dev view random and tries to read some data from it eventually. But that simply no longer works. So what do we do when we can't open dev view random? Well, yeah, then we just call the clock function to get the running time of the current process. And that should be used as the initial seed for all of the random number computation. So we tried to make our application more secure, but by calling cap enter, we actually made it a lot less secure. So what I learned in 2013, well, sandboxing is stupid, and you shouldn't use it. That's sort of my takeaway from it. It's no fun at all. You spend a lot of time figuring out why your program doesn't work. You run into these issues that you can actually only discover by tracing the application system call by system call and figuring out what's going wrong. There's no tooling that actually helps you along the way. You're on your own. And yeah, even if you get it working in the end, you still can't be certain that it actually works in the way you've sort of expected. So I want to sort of close off this part of my talk by putting this slide in there. If you're considering using sandboxing frameworks on Linux SDR right now, or on any Unix flavor, then please, please, please don't use it in any code that makes use of third-party libraries. Because you actually can't be certain what those libraries are doing on the inside. And the code in those libraries might actually be changing over time. Upstream might actually reimplement their secure random number generator by something that was shown on the previous slides. And your users will simply install the application, install of the dependencies, and they might actually end up with something that's insecure. So this is the reason why sandboxing frameworks work well for Google Chrome browser tabs. They make use of Seccom. And the reason for that is they only run C++ code in there that they've written themselves, or maintained themselves, or have part of their own distribution. That also explains why Pledge works really well for the OpenBSD people. They typically post these reports saying, we've ported over so many dozens or hundreds programs over to use Pledge. It works for them, because applications in OpenBSD tend to be fairly small, up to 10,000 lines of C code. And they make use of libraries that are all part of their base system. So that's why it works for them. But this also demonstrates why it didn't work well for me. And it also shows you why if you run PS on your system and take a look at all of the processes that are on there, that almost none of them use any sandboxing framework. So 2014 was over. I moved back to the Netherlands at the end of 2014. My girlfriend and I, we found a new apartment in which we wanted to live. So I was spending there a couple of days in a row, sitting on my knees, putting new floorboards in there. And it gave me some time to reflect on everything that I've been doing in 2014. So one of the things that I realized while I was working on my apartment and getting it all up in shape was this could all be avoided if we simply had a programming environment that didn't have this state transition in it. So where you didn't call Capenter to sandbox, but simply had sandboxing always turned on, where you could assume that the program was sandboxed. So in that case, you could design a C programming environment where sandboxing is always enabled. That's really important. That allows you to remove all sorts of functions that only work in a non-sandbox environment. So for example, the open call, you could just remove them entirely. And all of the remaining stuff, you could just re-implement it in such a way that it works well with sandboxing. So it really takes into account that it's running in the sandbox mode. The advantage of having such a model is you can now compile your application. And it will break in dozens of places, maybe even hundreds of places. But still, you know exactly which pieces of code you sort of need to inspect to get it working with sandboxing. So it gives you this really good guided approach of getting your program sandboxed. You start off with 100 compiler errors of your program not working. And then you sort of keep on working until you reach zero. And then your program works well in the sandbox mode. So for example, taking this piece of code that was from that crypto library, if you would sort of try to build it in such an environment that is sort of stripped down, you just get errors like these. So your compiler would first throw a warning saying, you're trying to call an open function. And I don't know if the existence of any function under that name. And later on, it tries to link that program. And your link will throw the error messages at the bottom saying that it can't actually combine all of the object files of your program into a program because there is no open function present. So in this case, it's really trivial to get this fixed. If you'd see a piece of code that tries to do stuff like this, you could just replace all of it by a simple call to functions like getRandom or arc4RandomBuff, depending on your operating system. Because these two functions, they can be properly implemented in such a way that they work well with sandboxing. So it's really about just detecting breakages because of sandboxing as early as possible. So what I did then is I, after I was finished decorating the apartment, opened up my laptop, started hacking again, I went to the page of the Bosic specification, which you can just freely access under this really annoying URL. So I can't expect you to memorize the numbers at the end. But you can just get this huge list of all of the functions that are part of the specification. And it's like hundreds of functions. And what I started doing was sort of redacting it. So just taking a list and removing everything off it that I thought was either sort of ancient cruft that you shouldn't be using anyway, or stuff that you should only make sense in a non-sandbox environment, or stuff that only makes sense in this privileged environment, and also added a couple of extensions on top, things that Linux has and BSD has, but it's not part of the Bosic specification. It's a bit sad that that's the case, because in my opinion, that the Bosic spec could do a lot better job at sort of catching up with what's being used in practice. And I ended up with this list that was sort of remarkably small. So just to give a comparison, Linux has about 300 system calls. FreeBSD has a bit more, I think, 400 around the ballpark. And this environment that I sort of came up with, looking at this list, would only give me sort of an operating system that it would only have 60 system calls in them. So that's tiny. Also, the number of data structures that was being used was really compact. So the programming interface for this environment against the operating system was just tiny compared to normal Unix flavors. So what I thought then was, if it's so tiny, wouldn't it make sense to sort of come up with a formal specification? Yeah. So this is basically what Cloud ABI is. It's nothing more than a specification of a compact Unix. And it's stored in this nicely formatted text file. Maurice wrote a lot of nice code to actually process that file and turn it into bindings. So it allows you to create C header files, system call tables, and even documentation. And those C header files and system call tables, those can be copied into source trees of operating systems to provide support. So those bindings are really low level. You shouldn't be using them in practice. This is really all sort of machine generated APIs. So instead of calling printf, you'd end up with snippets that look like this. But it can be used as sort of a basis for building other things on top. So if you want to build Cloud ABI programs, you can simply install those header files on your system and use a copy of Clang. Should be a pretty recent one, 3.8 or later, and call that in the right way to target Cloud ABI. If you just make sure that you sim link it under the right names and invoke the compiler under that through those sim links, then Clang is smart enough to figure out that it should be a cross compiler. So what I've also been working on is a C library called Cloud Lib C. I'm really bad at naming things. And it's basically just a compact C library built on top of Cloud ABI. It implements all of the relevant stuff from POSIX and ISOC. And compared to normal C libraries, it's sort of different. Instead of relying all of the file sort of user share, user share zone info, it has all of those data sets built in. So that means that it still works well in sandbox applications. There's also a large testing coverage of more than 900 tests right now. And it works fairly reliably. So here's a list of software I've already ported over to Cloud ABI. Looking at the time, I had a couple of projects sort of like bold over there that I wanted to look into and sort of show the patches to see how those have been ported over. But I'll keep that as an exercise left to the reader. So once it's been ported over, there's sort of a huge variety of things. So it ranges from crypto libraries, already the start of some GUI libraries have been ported over. You know, free type for font rendering and Cairo for canvas rendering. Some database related projects, so level DB, memcash D. And what I'm pretty excited about is that we've also ported over Python 3 recently. So at the end of my talk, you'll get a link to my blog and there's an article on there on how you can actually run a sandbox copy of Python even in there. We're also working on getting Django ported over. We can already run some really simple Django-based projects but there's still a lot of work that needs to be done to sort of make all of it work. I think even templating is sort of still somewhat broken in there. I need some more Python gurus to sort of get working. So what we've done is all of that software that's been ported over has also been sort of pre-packaged. So what we've done is we've created this repository of recipes of how software for Cloud API can be built. One of the things that I really dislike about package collections is that every package collection nowadays has its own package manager. So if you're using Python, then you have to call pip to upgrade all of the software that you've installed through that mechanism. Same with cpan, ctan, et cetera. So what we're doing is we're going in this different direction where we're actually generating packages for different operating systems. So we're creating Debian packages, RPMs, even packages for Homebrew and macOS. And you can install them by simply running sort of the native package manager in your system. It's also really nice because the package names have the architecture in them. You can install multiple copies of them for different architectures. So if you want to cross compile software for, say, an ARM, it's really easy. Just install like the ARM version of that package and you can compile directly on your MacBook some piece of code for an embedded system, which I think is like a huge plus. Running Cloud ABI software, there's a bunch of operating systems that support it by now or for which we provide ways of running it on there. So FreeBSD 11 and later have all of the support integrated. Linux, NetBSD, we've patched sets available for those as well. There is also an emulator available that allows you to run Cloud ABI programs on unpatched operating systems. So this is what I'm using on my MacBook. I can't expect people here in the audience to recompile the kernel of their MacBook. So there's a simple emulator out there that can at least be used to run Cloud ABI software. Unfortunately, it doesn't enforce any of the sandboxing under the hood. So if you would write a piece of inline assembly in your code that sort of tries to call a Mac OS system called directly, instead of going through the emulator, you can bypass security. But it's sort of good enough for testing software before you deploy it over to your Linux or BSD cluster. So running Cloud ABI software, this is a very simple copy of LS that I've sort of added to the slide. So instead of just reading the directory listing from a directory which you specify in a command line, it simply assumes that a file descriptor, in this case, file descriptor 0 corresponds to a directory, and file descriptor 1 corresponds to your terminal. So if you want to run this, you end up doing this. You end up building it and running it like this. So it's a bit nasty. You sort of pass slash EDC over and standard in. And voila, you've got a copy of LS that can only access a directory and access your terminal. That's it. So this works, but it doesn't really scale. Think of the following use case. You've got a web server that can listen on 10 IP addresses and has 40 different virtual hosts. And for all of those, you need one file descriptor. Passing this in on the command line doesn't make any sense at all. It's a mess. So I've been working on an alternative for that called cloudABI-run. And what you basically do is you just invoke it like this. You say, I want to run this executable, and I want to provide it a configuration file of how it needs to be started. And this configuration file is sort of a replacement for command line arguments. And it's sort of YAML-like. And where it differs from YAML or extends on YAML is that it's actually, it has file descriptors as a native data type. So consider this simple web server for which we're writing a configuration file. Normally, you'd write something down like this where you say it needs to listen on this IP address and needs to access these files on disk. With cloudABI-run, you sort of add annotations to them where you say, this is not a string of some kind of IP address. This really needs to be a socket on which we want to listen. And that's what you do with those exclamation tags that you see in there. That's sort of a standard feature of YAML where you can introduce typing information into the definitions. So what happens is this file sort of gets parsed and gets converted by cloudABI-run into this format, namely where all of the files, all the resources are replaced by file descriptor numbers. And this is being passed on to the program. There is also an API for accessing those files from within the program, of course. So instead of using the in-at-main entry point, you now use an alternative entry point called program main where you have some accessor functions for iterating over maps and dictionaries, oh, sorry, maps and sequences. And you also have functions for accessing Booleans, integers, strings, file descriptors. So what's the advantage of using cloudABI-run? You now have a unified configuration file format. There is no need to write your own configuration file parsers. Programs tend to become smaller as a result of using this. And there is also no way of actually accidentally leaking resources into a program. What's really awesome about this mechanism is you can just, as long as you make sure that you're not using any exclamation mark tags for things that you don't want to give away to a process, you can run stuff that you don't even trust. So you can sort of say, I'm providing two file descriptors, one of my standard in on the terminal, one of a standard out on the terminal as well. And then the process can only read and write through a terminal and can't do anything else. And that's sort of really ensured by using this utility that there's no accidental leakage of stuff. Another really cool thing of this mechanism is that it makes programs really easy to test. So because you know what a program is going to access, you also know that it can't actually interfere with your production setup, for example. So if you have a production and a staging setup, you only need to sort of check the configuration file to make sure that you don't list file descriptors that correspond to servers or data sets belong to the production setup. And then you can safely run your process knowing that it won't interfere. So what have I shown you so far in this presentation? I've been talking about the Cloud ABI project that I've been working on with a bunch of other people. And it's a framework for building testable and secure programs. And it consists of a couple of components, namely the raw definitions of the ABI, the C library that's built on top of that, the package collection for pre-packaged programs, and the Cloud ABI run utility that can be used to safely spawn those sandbox processes. So now I want to close off this talk by sort of sketching a roadmap for the future. So what is going to happen until the end of time? It's 2038. So I've got some short-term goals. I'm not saying that they're personal goals, but these are goals for the project, I think. Things that the project should explore. So first of all, we need support for more programming languages. Right now, we have support for C, C++, Python, and Lua. I think so, just four programming languages, scripting languages. But this needs to be more. Nowadays, you see a lot of people writing software and Go and in Rust and all sorts of other modern languages. We need to sort of be on board with that as well, so we can actually welcome more people into the project. Also, so far, we've had a really strong focus on getting the libraries to work. As you saw in the previous slides, there's a whole bunch of libraries that have already been packaged. But now it's the time to actually get full programs to work. We have all of the dependencies ported over. Now we can actually start building full programs. Having a sandboxed MySQL server where you can only sort of say, like, this is your data directory, and this is your socket on which you're receiving incoming SQL queries, that's pretty awesome. Same holds for Node.js, if you want to run sandbox web applications, of course. Linux support, right now it's an external repository. This needs to be integrated, period. Or at least the things that we can get rid of need to be upstreamed into the official Linux kernel. So in the end, all of Cloud API support is nothing more than a simple kernel module that you can load into a stock Linux kernel. And of course, there's always a need to improve the documentation, always. And I already have a couple of how-tos on the Cloud API blog, but we really need to extend on that. There needs to be good developer documentation as well. Long-term goal for the project. So a lot of people, they sort of say to me, like, Cloud API is the stupidest name I've ever heard. It doesn't make any sense. The reason for that is that I often also have to show this slide, sort of explaining the sort of original mindset I had for the project. So, Cloud API is a way where you can do dependency injection for Unix programs. And what would happen if you could actually make use of that as part of some kind of cluster management system? So say you want to deploy a pipeline of database servers, web frontends, batch jobs, all of that stuff, and you'd make use of this model. Then you could actually design some pretty fancy stuff. So first of all, you could build some kind of GUI where you could drag and drop programs on a canvas and hook them up through like arrows, say like, this is a web frontend that needs to talk to this database server. You could just click a play button and it would automatically set it up. It would know how to sort of connect all of those programs together. You could also even have like monitoring dashboards based on this concept, where the cluster management system knows the relationship between programs, so it can actually give you accurate monitoring for that. Also, a very interesting aspect is that this kind of mechanism could be used for setting up the connections between those processes securely. So if it knows that it's going to start up two processes on the same server, it doesn't even need to care about cryptography because it's already sort of secured. Nobody can eavesdrop on those kinds of connections. But if it's starting those two processes in different data centers, then the cluster management system could be responsible for creating the keys, sending them over to the two servers running the processes. And the server could then automatically set up a secure channel between those two processes, which simplifies this kind of management a lot. I've been using Kubernetes a lot. And we have to spend quite a lot of time getting all of the crypto and all of the key exchange right. And this could be solved automatically. So my long-term goal is maybe we could extend tools like Kubernetes to have proper Cloud API support and do this out of the box. So now I'm at the last one or two slides of my talk. I briefly want to talk about the sustainability of this project. I've been working on this project for two years. I had the luck of being able to work on this for one full year. Unfortunately, because there is no full-time headcount on this project anymore, the things that I've shown on the previous slide are actually infeasible at this moment. And that's why this is a call for help to the audience. If you think that this is a cool project, at least start using it. Try exploring it. See whether it works for you. You'll quickly run into bugs, hopefully simple requests. And it would be awesome if the Cloud API team can grow, because I think it's a really valuable project. In my opinion, it's still the only solution that allows you to build secure applications just easily compared to all of the existing frameworks out there. So please give it a try. I want to give my special thanks to a couple of people. Some of them are sitting in the audience, good friends of mine. I've been either pestering me with bug reports or just giving me mental support. Or Katouche, our cat, walking on my keyboard all day long, racking my code. I want to thank the people at Koumina Bay Bay who've also been supporting me over the last half year and have allowed to work on this part time. So this concludes my talk. Here's a couple of links. Be sure to check them out. Are there any questions? So thank you for doing this, because it's really important that we finally get a secure Linux and open source and free software kernel. And my question is, first of all, the problems that you noted were all more or less to do with the VFS. And you basically said you don't have a root VFS. You can't do open. Why don't you do something like a CX root and then bind in the appropriate global state that is benign? And my second question is that you talk about the save issue with Firefox. Why don't you have something like a Power Box? Or have you thought about how to do a Power Box? So to answer your first question, which was, why don't you have a way of organizing the file system layout? So what I've noticed is that this is basically also the mindset that operating systems like plan 9 have been using. Have proper APIs where processes can sort of create layouts of their own file system namespaces. Everything is done in a file system namespace. But my observation is that it sort of quickly gets messy and bloaty. So in the case of a file system, what you can do is you can sort of pass it on to new processes, to child processes, to helper processes. But what you'll see in practice is that nobody will bother to sort of clean those up. So then you sort of end up in a state where you have like a bunch of sort of privilege separated processes. But in the end, they still make use of this bloaty file system namespace where there's a lot of stuff in there that processes don't need to access. So basically how this differs from what you propose, how Cloud API differs, is that it's a file script namespace. It's a flat namespace. And my hope is, compared to using a file like a tree-based namespace, is that this will not leak as quickly. That people are a bit more thoughtful about this. Well, maybe it's a bit overly optimistic, but we'll see. To answer your second question, so like the example I gave with the browser, I mean, it's just a simple example that could be substituted for any different application. So for example, your text editor has the same issue, of course. When you're running VIM, it can also access a lot of things in the meantime that shouldn't be accessible. And yeah, that could be solved by making use of different sort of helper tools. But the nice thing about this approach is that it actually enforces the use of a mechanism like that. It's not about just that I've got a whole solution for that in place already set up. But the idea behind Cloud API is to come up with an environment that forces people to design applications in this privileged, separated way. That's sort of trying to solve it at the root and not at the top. That's what the Cloud API project is about. Did I answer your questions? Are there any other questions? Oh, God. Are you aware of E? And so they have a mechanism called BATS. And that more or less does exactly what you're talking about with respect to automatically creating secure channels between multiple computers over the network and doing consistency things. So I'm not aware of that project specifically. What's the name of that again? E, just the letter E. That's it. OK. I'll look into that then. If you look for Mark Miller and E, then you'll find it. Ah, thanks. Well, then if nobody else has questions, then thanks for attending my talk. Later today, there's going to be a talk in a BSD dev room where I sort of go into more details on the kernel side of how all of this works. Well, I guess not all of you should be showing up because the room is a lot smaller than this one. All right. Thanks. That's for you. Thanks. Enjoy. Yeah, so the charger was mined. That's the second speaker. The second speaker? More about the kernel side. Yeah. Yeah, so I'm going to discuss how it sort of works in previously. How the kernel forces the sample. Well, because the point is I originally sort of wanted to give just one call. Because I wasn't sure I would get into the same track. I also had a backup plan where I did the same sufficient for the BSD. But then both got accepted. Yeah, so I said, one sufficient. I thought one thought was insufficient, but then they forced me to send it off as well. Of course. So that's what I'm going to be seeing. Yeah. It's exciting to hear about the full size of this room. Yeah. So it's in the BSD dev room. So it will be nonstop green and sort of showing how it works in the kernel side. How far this, how quickly these things go for planning. Yeah. Yeah. Yeah. That's fine. That's fine. Yeah, it's a very personal. I think it's a very good branch. Yeah. Yeah. Yeah. Yeah. Yeah. I mean, it's also a good thing. I think it's a very good thing. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. But what is it? What's because of the sand blocks? So I guess I should go back. We're stuck if the next picture shows up. Yeah. Yeah, but we should be able to go up more today. Morning. Hi. Good morning sir. What's the big day? Now I have to be comfortable. Rest. Excellent. We do have this converter. Just a case. I got everything that I tested with you. Thank you. Do you need a fresh water? Thank you. Yeah, thanks. So who's going to get the basil for me? Plenty of time, right?