 My name is Badis and I'm from the FreeBSI project. We often meet together to share our suits and vision about what's going to be the next big thing in IT. Or have a long physical, philosophical discussion about technology in general. That's how we predicted that the cloud would be a thing before the world was even invented. I think it was around 5pm, a beautiful afternoon. Who are we kidding there? It was mostly like 2 in the morning. Yeah, but probably it was some random bar. I think it was a glass of red can of wine. Burgundy, Burgundy. We're in France. You can say you're drinking that thing. So, Burgundy was Burgundy. So, I started complaining that Burgundy didn't have a taste. So, if not, again, we're in France. We were having a Burgundy, or a Californian one in that case. Well, so, as I was saying, the wine didn't have any flavor in it. And that's when it hit me. Oh my God! This is after the FreeBSI, you guys suck! You guys don't have flavor! Okay, so what is flavor? Flavor is a very interesting concept. I'm not aware of any other package manager in Unixland that implements the same functionality. Basically, it allows providing packages combined with a different set of options. So that's obviously very convenient from the dependency point of view. Since according to the option that you set for the combination, the final battery will change. I might end up linking to different libraries, obviously. So, since you want to be in control, but providing packages combined with a good set of options is quite complex. Why sometimes it's not possible to have a good default, because it's a hard one, right? And that's why the flavor kicks in. For example, against Al-Sendal, or with or without Al-Dab support, etc. It's completely different from what we call sub-packages, which are just split packages. These are typically used when you have a software that comes with a huge amount of data, for example, like audio or graphics or games packages. And these rarely change, while the main buyer does change each time it is a day. So instead of having a huge packet that comes with a complete set, you just update one small sub-package. It can also be used for things that use modules or add components that have a lot of different dependencies. PHP is a good example of that. On OpenBSD, for example, we combined it with pretty much all the possible options. So the build requirements are big, but the port only needs to be built once, and since the package itself is then built into several sub-packages, you only get to install what you're reading, like PHP iMap or PHP MySQL, etc. With that last one, you really took the wrong example. On FreeBSD, we have a fine-grained split package for PHP, so if you want PHP with iMap, you just install PHP5.iMap. My point is that actually sub-packages allows you not to have to deal with fine-grained packages. If I understand correctly how you port three ports, you still need to be able to use PHP modules one by one, which would be everything you want. Yeah, you're correct there. There are no really sub-packages, and it would be nicer if you had them. If you're speaking about flavors, a good example would be probably OpenELDAP client built without sub-support. Right, so if I need sub-support in OpenELDAP on FreeBSD, I assume that I need to build it myself, right? Okay, that's fine, but what will happen when I suddenly run package update and package upgrade? Yeah, probably bad things, like removing half of your packages. Nice. So, yes. It's true that we do not have the flavors nor sub-packages, but there are a lot of ongoing works. Actually, flavors should be committed in the next hour's days. We talked about it yesterday. So, the thing is, that work is pretty hard. It breaks the design of the way some tools that are heavily used by some user works, for example, Portmaster and Portupgrade. And those tools are right now barely maintained. So, as soon as we make such modification, we have no one to update those. So, on FreeBSD engineer, I will try to have a great path for users to try to avoid breaking things. Keep in mind that we do not release a package set, but the Post3 is a rolling release, not tied to a given release, so such change needs to be smooth when it arrives. Which reminds me, you guys do not support upgrading packages on a given release. Do you? Actually, we do support upgrading packages on a given release, but we do not provide the actual binary packages. Yeah. Yeah, okay, it's true that you need some kind of build books or something where you can distribute packages a day from. But there is work in progress in this area, and we should be able, hopefully, to be able to provide a data binary packages in the next year or so, famous last year. So, we just need to agree on the work of the team responsible for it and get in-rewarding, fresh culture, et cetera. So, it's not a technical problem, it's not a very moral work, but talking about package data, it's important to note that on OpenBSD, a lot of operations are done as completely different than previous users. So, you have different users for fetching, extracting, installing, changing the signatures, et cetera. We, for example, don't really want to go up on the ALF as root or anything. Well, I think you guys still do not draw packages when using the fetch with a package. Can you comment on that? Actually, that's not true. Package uses Capsicum to soundbox everywhere it is possible to make a soundbox since Capsicum exists basically. And package also uses Unprivileged User to fetch package or in every areas where we don't need root privileges. So, while soundboxing support is there for a long time, Unprivileged User mechanism has been added quite recently, but I actually got it in before you did from a few days. Yeah, yeah, yeah. Limfetch commit was pretty good. Anyway, back to our topic. We've also tried very hard to provide proper, great path for our users, obviously. But the difference is that people have to deal with legacy or maintain package wrapper that you guys have like the portmaster or the grade board, super-room, whatever. Our package crews are designed to provide everything one needs for package management to meet external efforts. So, don't forget, we have a very long tradition of providing proper binary packages for pushing people to actually combine them. Well, that's also true for FreeBSD now. It's been a while now that we are building binary packages. Most of the tools you are speaking about are mostly to use the POS3 directly on the live system rather than using the binary package, which I think is a user which is not supported by OpenBSD. No, no. Now FreeBSD has first-class cities and non-binary packages. It's perfectly supported by OpenBSD. We just don't encourage people to do it because for 99% of the time, it's just not needed. Yeah, one of the things about the FreeBSD POS3 you need to keep in mind is that it works on an ultra-ported version of FreeBSD, which, yes, it reminds me that you only support one version of OpenBSD and only for six months. Well, you are correct that for packages we only support the current release, which at this time is 6.1. Operating system, base system itself is supported for two releases. And aside from current snapshots, our POS3 is also tagged to a specific release. That's a design decision. We don't want to enforce to our user to create a new major version of a particular software. And we don't want to maintain four different versions of the same software to prevent that, which is why our POS3 does not follow a rolling release model, et cetera, for current POS3. But considering the fact that we have regular releases every six months and our packages don't have the time to get too old anyway, regarding the support policy itself, it's pretty basic. We support base system for current release and the previous one, packages only the current one. As I said, there's only an expression to improve that part. So that's true, that this means that you need to create at least once a year if you want to run a supported OpenBSD. I don't think that's a bad thing. I'd rather create open in small steps than the one certified years having to deal and handle multiple and invasive changes. I don't understand the meaning for LTS like releases. I just don't like it when I'm the one responsible or great. So, that's it. What can be good to have someone turn support? What the fuck is more policy? I mean, extended support, normal support. How come FreeBSD 10.0 was still supported while 10.2 wasn't? I mean, this is so very confusing and you know support can be good if you don't understand how it works. Come on, that's easy. I will read it for you so that you understand. So, we have the normal releases. Those are releases which are published from a stable branch. We're supported by security officer for a minimum of 12 months after the release and for sufficient amount of time if needed to ensure that a new release for at least is out for at least 3 months before the older normal release expires. And then, you get the extended one. So, selected release, normally every second release plus the last one from each stable branch were supported by security officer for a minimum of 24 months after the release and for sufficient additional time if needed to ensure that there is a newer extended release for the last 3 months before the older extended release expires. It's easy, no? Yeah, no, okay. I agree. It's a mess. Well, actually, I should say it was a mess. Furthermore, it was causing a lot of issues when maintaining the port 3 as we had to wait for at least 2 years with this model to be able to use some modern tools in the port 3. So, it was kind of a pain. Well, we changed that with FreeBSD11.0. So, now the model is way easier to understand. So, each major version of our stable branch is explicitly supported for 5 years. And then, we can issue a new dot release whenever we want without extending that date. When we issue one, the previous one is maintained for only 3 months. So, you have 3 months to upgrade. So, going from 11.1 to 11.2 and then 11.3. So, that way, it will benefit stability for 5 years and at the same time, they have the new features. How do you finish it? Yeah. Well, it looks like FreeBSD support model keeps newer features out of the hands of users because it can be years before they actually see the new features in the release, right? So, it reduces real-world testing and basically benefits no one. In my opinion, OpenBSD model is super easy to understand and keeps the code stable but still pretty fresh. Whatever is in current at the starting period of time will end up in the release which would take at the very worst 6 months. You seem to have misunderstood one of the benefits of the new release model. New features, as soon as they are not breaking binary compatibility or things like that, are merged to the stable branch. So, as soon as we need a new feature we'll just issue a new release and a new problem is solved. So, you get new release supporting those new features anyway. Well, you did say that you had to wait for at least 2 years before being able to use the modern tool available with the previous model. Oh, previous model, okay. Well, anyway, we do things differently. We're not afraid of breaking binary compatibility in current and for our upcoming release, obviously. So, we don't do that stuff that merge of backwards usually. But, as you put it, your process is kind of less or less. And may have less to do. So, given we do support binary upgrade, it's very easy on FreeBSD to upgrade from a minor version to another minor version. By the way, binary upgrade also works very nicely across major releases in FreeBSD. But hey, I must be losing you somewhere here because you do not support binary upgrades, neither for security fixes or across releases. Seriously, it should be very tedious to maintain some OpenBSD boxes in production. Yeah, I see where you're going here. The way you put it is not entirely true. Binary upgrades between releases are and are always being perfectly supported. What is not supported are in-place upgrades of the basis from one release to the other. But is that really an issue? I mean, supporting in-place major upgrade would not prevent us from having to like reboot anyway. So, for me, I think your great process of OpenBSD is just one of the easiest and fastest ever encountered. Just reboot on the new release, boot on the PSD around this kernel and it will do the rest for you in like five minutes. And also, thanks to our Auto-Install and Auto-Upgrade functionality, you can give it the path to enhance or find the DHCP. And you won't even need any interaction. You can also upgrade your packages to much in release and add these to the fact that sysmerge the kernel configuration files merger is automatically run on boot. Well, we pretty much left with nothing to do now. Yeah, well, sounds okay, but what happens if you have to upgrade for security patches? Okay. Until a few months ago, updates within a particular release were only provided in the form of CBS patches. This has changed since the 6.1 release and the new syspatch utility which is a base system update tool that will basically fetch, verify and apply binary updates on base systems. It tries to design what our installer does so it's very simple, secure, fast Well, on the FreeBSD side we do support, as I said earlier, in-place binary upgrades via the FreeBSD update tool. So the basic design behind FreeBSD update is that we create binary updates and we binary patch the system with the changes. So it is very convenient to receive security fixes and very fast for that. FreeBSD update also allows you to upgrade from one major version to one major release to another major release in place and the procedure is basically what happened under the hood. First it installed a new kernel then it reboots on the new kernel then it installs the user and manage configuration files and remove the files that are not needed anymore in the new release and that works. It works fairly nicely for a while now but fetching all the binary patches upgrading from a major release to another major release can be very, very long. Another issue is that producing the packages is not really trivial for FreeBSD update as it needs reproducible builds to be effective. That's why we're now looking forward to be able to provide a new mechanism based on package itself. To be honest, there is also a job act about in-place upgrades and we need to maintain strong backed compatibility on some kernel interface versus the rated user-land tools that goes with. A particular case is DLFS it's an interesting thing to look at so let's consider the version in the kernel goes with the version in the user-land which is nice so if they modify the kernel interface, you modify the user-land tool that goes with and everything is fine but on FreeBSD, because you reboot on the new kernel first, then you might end up with a user-land tool that are not compatible anymore with the kernel you're putting in so when we are receiving the packages to update DLFS and there is an incompatibility intruders then we need to make the compatibility scheme ourselves. So... Okay, that sounds quite complex. I mean, in-place upgrades can be interesting when the upgrade takes a while, for example. In theory, it would prevent like long down time but the reality in production should be resilient and services should be redundant so it's not generally such a problem. Also, the release of the upgrade process on OpenBSD is literally the fastest one I've ever used. If in-place upgrade actually meant reloading I mean, updating and reloading both the user-land and the kernel without having to reboot that I'm sure it would have evolved. So that's it, a very deep great pass an interesting policy that we have on FreeBSD is polar policy principle of least astonishment. It's a very strong policy on the FreeBSD saying that we should try very, very hard to make upgrades as seamless as possible and avoid breaking end-user boxes as much as possible. Well, in general, we're not afraid of breaking backward compatibility when we think it makes sense, of course and help to push our ideas forward. That said, I can understand the need for a polar for some time, but not when it goes against bad basic security apparatus. For example, just to satisfy third-party clients, you guys get TSA encryption, AES, CBC Cypher and SSH-1 support in your OpenSSH for a long time after upstream which is us, dropped it. That's the kind of compromise that we're not going to make. Well, that's not entirely true. Pola does not prevent from making those change, but if they are done, they should be driven in a manner so that the user are one long before. This is particularly true on a given branch. We usually make big changes between a new major release. On newer branch, they're just then removed. Well, then, let me read this. According to previous DSM revision 303716 dated August 3rd, 2016 removed TSA from default Cypher list and disabled SSH-1. Abstracted this a long time ago but we get a TSA and SSH-1 in previous year for reasons which goes down to Pola. So that was a good time to catch up. Anyway, speaking about delivering binary upgrades you guys must have a very hard time building the thing considering you're still using the giant look almost everywhere, meaning you cannot use efficiently multiple cores. Well, for rather desktop-like usage, our big log SMP implementation model, the internal look, is good enough. The reasons that most of the time in workstation you only have a handful of not-of-force like between 208 and only one socket. So our actual scheduler isn't bad. It's just that it's a bit old to say the least and was written for machines. That's not considered things like, for example, the cache distance between cores, and that's the main reason why machines with several sockets often have a lower performance than the ones with only one socket. There's that less ping only lower. So we can also use 24 cores but in the context of huge building for example where much better performance incatenate the works of 6, 5, 4 cores machine for the time being. That's true. How the change can be done in the OpenBSD model? I mean, on FreeBSD it took a lot of time to get most of the architectural work done so that we can have proper SMP and it also led us to some of our very good releases like FreeBSD 5. I'm not saying that the road we took is the one true way but I can't see how this can be achieved in an incremental way that is yours. A few things can be incremental because they're not directly related to the scheduler itself. Several scheduling related issues that we haven't looked in BSD can in fact from a spin-locking in the bar thread or posix B-thread implementations but that just drastically improved since we implemented a few tests and made our B-thread library use it. And in contrary to that, OpenBSD scales very nicely on big user network but now its role performance on bar with FreeBSD probably not but our priorities are different and we are okay using a bit in this area if we can get more security and simplicity. Actually I'm going even further than that I would say that with rather crash and added you could detect an unset behavior. Well to be honest, SMP is something that is always evolving right now our next challenge on FreeBSD side are to have better number support to improve the overall locking systems by using lockless mechanism where possible by using for example concurrency kits. What is the current status on that on OpenBSD? Well, our entire SCSI stack and current providing already fully SMP for example and recently there's been some huge progress on making our network stack more SMP friendly. The goal of the network being able to use multiple threads to forward traffic for example. I don't think you would argue that modern scheduling is hard. Most operating system has to do it and we do it again multiple times. We are learning from others OS experience and I usually with OpenBSD we are trained to implement something that is simple and match the project goals. So as you say, it wasn't an easy road for you. So that is why sometimes we see the big behind certain aspects. We take the time to do it according to our standards and all we just don't do it. So what are you here? Maybe you can explain me something in OpenBSD I do not understand. You seem to keep writing again and again your own tools when there are already BSD license counterparts. I mean HDPD, SMTPD, VMM, etc. Aren't you suffering some kind of NIH syndrome? Well, that is actually a very good question. I am glad you asked because there is actually in our opinion a very objective reason to do that. The first one would be trust. We have a coding style, obviously practice and process that makes us confident in what we develop. Another reason is also control. We know someone will not decide to change the software license one day to the next or start adding nodes for each and every crazy current case. Does it out there that only two people would use for example? Looking at how many CVs impacted NTPD or OpenSSL in the last couple years it should be a good hint as to why OpenNTPD was created and why LibreSSL was formed from OpenSSL. So if I am not mistaken for example a lot of your security advisory has been related to the NTPD. I think you need a system, the so called reference implementation. So I don't think it's really having an age syndrome wanting to write a second implementation. For the example you took, okay I can understand it but I mean when you have already some BSD quality alternatives you're still doing it. What about B-Hive? It was working, it could easily fit the security requirements about security and sandboxing. So why yet another implementation? There's been an initial reporting trial a few years ago by Mike Locking but compiling a single file ended up being a huge amount of work so we'll let it go and run. When you're conflicted with such trouble you really need to ask yourself whether it's not worth just creating something from scratch instead of reporting something that is not portable. The situation I agree may have changed since now OSS has been in confrontation with X-Hive but that was one of the reasons that VNM was created. I would also add that it helps us providing the basis then that we want I mean the basis then that for us just works without having to depend on the choice done by the external project. Right, but another example I could have is a capsicum you decided to make your own sandboxing mechanism instead of reporting that one. Oh but there is a very good reason for that actually but since you've brought up the subject of security let's talk about that and we'll compare sandbox implementation later on. So as some of you know, most demand runs with privilege separation on OpenBSD that is most of the code is run true to and as a non-privilege user OpenSSH led the way on this topic years ago they also use privilege replication for dropping privileges as soon as possible A good and simple example to look at is NTBD again. It's a very standard OpenBSD unit so it's written with principle of least privilege in mind and so not only does privilege and privilege drop but in addition to this it has a completely privilege separated TLS speaker for the constraint feature with no memory sharing or FD passing and with a very limited amount of allowable system calls thanks to Clash which I will describe later on. The constraint feature that I talked about of NTBD basically queries the time from a trust and web server over HTTPS reducing the risk of a man in the middle attack by comparing that time with the one that the remote NTB server gave us. So for NTB well, you're right but there is one price behind that you have a half baking permutation you have an implementation that cannot authenticate the peer you're receiving the time from and this could be a huge problem and you're not showing the standardized mechanism in that case you miss half of the feature NTBD servers to provide and yes, I agree on the fact that most people won't care about some of those that's it. I would love that to get something out of the NTBD in the base system but an open NTBD is probably too light. I'm actually describing it exactly open NTBDs it actually does not need to authenticate it tends to constraints and it does not need to implement the kitchen sink because no one cares and if one does then one can install the reference implementation and it's not always about math and algorithm and sometimes good enough really means really enough. Anyway, on a really good topic OpenBSD is also well known for its numerous exploiting the Asian techniques and it's important to note that all of these have been enabled by default for some of them for years and are very hard or even impossible to disable. So, let me give you a few examples like we have a web AS and R2 to grant a buffer on the prototypes. We have a WNSOAS a memory page that can be either writable or executable in both the kernel and the usernet and we have Propolis the step matching protection using a balance checking and wiring we have PI position independent executable also for static diaries to exactly a random address which stops stuff return to IPC type text since not too long ago we had a car the kernel address randomized link which will generate a unique kernel on each boot with internal structures preventing leaking internal current functions pointers and more objects and we also just got TROPSLAND to live in the availability of attacker to exploit return oriented programming like that by jumping around on the programs. So, obviously each of those can be encoded around the ground so I won't go into details but I want to insist on the fact that the way we approach security is that we always assume to be running in a hostile environment we also refuse to implement dangerous functions like like Word EXP and then Lipsy spawning the shell to perform word expansions this is completely crazy True We also provide some Propolis mechanism about ISOLOR we have an implementation which is in review right now opening VM people to be able to review it on our side we have the MAC framework which is a very interesting framework it's monitoring access control it allows to restrict many many things so with MAC you can restrict user access to system resources including not seeing sockets opened by other users or many other stuff you can also have a file like policy on file system to be way stricter than the regular system rights you can restrict network interface accesses you can limit the scope of the process one can see compartmentalizing them into partition and way more things another interesting feature that we have is OpenBSM it's a full feature audit system which you can use to monitor everything that happened on the system and you can distribute the log over central server it also supports the Linux version of the protocol for the centralization well see all this technology I mentioned are for me very interesting in theory I do agree but in real life I almost never see them in action because they are too complex to use and next to impossible to audit well let's go on the sandbox part Capsicum is a very nice sandboxing mechanism that we have on FreeBSD it leverages the concept of capabilities what is very nice about it is once you are inside the sandbox there is absolutely no way you can exit it even child process inner into capabilities so that's by design it is really designed for developers to secure their own application by strictly restricting the capability of an application to only what it really needs to be able to and strictly what it is really needs to be able to do we have started converting most of the base system to use it what are you there yet because yes the design of Capsicum allows no compromise so it's not always that easy to convert existing software to Capsicum yeah that's where I wanted to go actually Capsicum it's too complicated that's why it doesn't have much use by default Capsicum is actually a very good summary of what OpenBSD project is about developer practical and affordable security meaning simple and easy to implement and it's enabled by default almost everywhere in the system I mean 30% of the base system was pledged after only two months today it's more like 85 to 90% I don't have the exact number and even some most supports like Chromium are pledged so anyway talk about pledge itself for us it's designed to serve two goals basically encourage refactoring towards safer models and reduce public exposure to the current model so people often compare it to a second BPF on legs other pledges not a system called spiral but rather somewhat like a facility to explicitly allow a group of system code in the process with some sort of pre-claring profiles like I9's shown, DNS, TTY and obviously a pledge process is forced into a restrictive service operating mode where abilities can be reduced but never regained and if a restricted operation is attended then the process is killed with a catchable C-deboard in theory I agree that capability basis security may be more advanced and probably yes but what is a feature that is too complex to be widely implemented another security feature that we do have in 3BSD and we have it for a while is gel it allows to create prison container we have it on 3BSD since 3BSD 4 I guess if I remember correctly it's very simple and easy to use almost everything can be is disabled by default can be restricted inside the gel so you can restrict network, file system access CPU, memory, routing tables and nowadays there can even be nested on 3BSD data set dedicated or have your network about that regard I do agree that it's okay there's been initially 4 years ago called CIS gel but it was abandoned because of an inherent design issue in CIS trace on which the tool was placed and that would basically allow fading gel by exploiting a race condition so getting tired so I think it's time to go to somebody else let's do that thank you and see you after the break