WEBVTT 00:00.000 --> 00:09.000 All right, well, thank you. 00:09.000 --> 00:11.000 I have a student's part of yes. 00:11.000 --> 00:13.000 Thank you very much for having me here. 00:13.000 --> 00:14.000 My name is Luca. 00:14.000 --> 00:19.000 By day, I work as a software engineer in the Linux Azure group, 00:19.000 --> 00:21.000 in the Linux system group and Microsoft. 00:21.000 --> 00:24.000 By night, I am involved in various open source projects, 00:24.000 --> 00:26.000 most relevant for this talk. 00:26.000 --> 00:29.000 I am one of the upstream containers and developers of SystemD. 00:29.000 --> 00:34.000 Now, today I am here to talk to you about what I think is one of the latest things 00:34.000 --> 00:37.000 to come out of this is the project, which is a particle OS. 00:37.000 --> 00:40.000 It's purpose is to let you build immutable systems. 00:40.000 --> 00:44.000 So, first of all, quick look at the agenda. 00:44.000 --> 00:48.000 We are going to look at why do we want this thing. 00:48.000 --> 00:51.000 What tools do we use to build one? 00:51.000 --> 00:53.000 What do we build it from? 00:53.000 --> 00:54.000 What are the components? 00:54.000 --> 00:56.000 How do we put it together? 00:56.000 --> 01:00.000 Where do we put it together and then what we end up with at the end? 01:00.000 --> 01:04.000 Up through some delicious immutable image. 01:04.000 --> 01:07.000 Now, I don't know if I'm not going to do all the items, 01:07.000 --> 01:11.000 not in a time, but there's lies online on the schedule. 01:11.000 --> 01:14.000 You can download them or the bootings are links, 01:14.000 --> 01:16.000 like, clickable, if you don't know, and about these things, 01:16.000 --> 01:18.000 you can check them online. 01:18.000 --> 01:21.000 Only one thing I want to mention here, 01:21.000 --> 01:23.000 because this is the distribution of everyone. 01:23.000 --> 01:27.000 So, in order to build an immutable system, 01:27.000 --> 01:30.000 one of the requirements that we have at least we have to use 01:30.000 --> 01:32.000 is the metric user. 01:32.000 --> 01:34.000 As a concept, this just means that your OS, 01:34.000 --> 01:36.000 when the three or the distribution of the three, 01:36.000 --> 01:38.000 is self-contained under the user. 01:38.000 --> 01:42.000 Everything else can be regenerated and boot when needed 01:42.000 --> 01:44.000 or installed or on factor Z. 01:44.000 --> 01:48.000 Now, in practice, if you are a distribution package 01:48.000 --> 01:52.000 of the developer, in 99% of the cases, this just means 01:52.000 --> 01:57.000 if you need system users or groups, use cusers.d to create them. 01:57.000 --> 02:00.000 Don't handle your script, bash script and your maintenance scripts. 02:00.000 --> 02:04.000 And if your software needs some directories of files 02:04.000 --> 02:08.000 under var, or if you see, use tmp files.d instead of, 02:08.000 --> 02:10.000 again, under all your maintenance script, 02:10.000 --> 02:11.000 your postings, or whatever. 02:11.000 --> 02:13.000 Because that way we can recreate them on boot. 02:13.000 --> 02:17.000 These are decorative tools with the creating configuration 02:17.000 --> 02:20.000 that can be used for these purpose. 02:20.000 --> 02:25.000 Now, first of all, what is even an immutable system? 02:25.000 --> 02:28.000 The embedded people have been shipping redone images 02:28.000 --> 02:31.000 for the devices for ever, right? 02:31.000 --> 02:33.000 So there's not a new concept. 02:33.000 --> 02:36.000 What we're trying to do here is to push the envelope 02:36.000 --> 02:37.000 a little further. 02:37.000 --> 02:39.000 And especially from the security point of view, 02:39.000 --> 02:42.000 I know to do that, we need to establish some ground rules. 02:42.000 --> 02:44.000 Now, this is, of course, my view and the view of other people, 02:44.000 --> 02:48.000 but I might not be universal, but if I talk so I'm going to tell you about my view. 02:48.000 --> 02:51.000 Now, an immutable system means immutable. 02:51.000 --> 02:55.000 If you just need to run some commands as root 02:55.000 --> 02:58.000 and you persist to change the content of your OS, 02:58.000 --> 03:00.000 it's not really immutable. 03:00.000 --> 03:03.000 If you just do mount, minus, or re-mount, 03:03.000 --> 03:06.000 or W, and you get a completely rightable 03:06.000 --> 03:08.000 and persisting of the system, it's not an immutable system. 03:08.000 --> 03:11.000 If you run some, as napper, zipper, 03:11.000 --> 03:13.000 or pianos, take commands that you can add, 03:13.000 --> 03:17.000 arbitrary programs to that, and then just boot into it, 03:17.000 --> 03:20.000 locally, it's not really an immutable system anymore. 03:20.000 --> 03:21.000 Now, is it? 03:21.000 --> 03:24.000 Now, the way to look at this, in my view, 03:24.000 --> 03:29.000 is to look at the, to think about the threat model. 03:29.000 --> 03:32.000 Now, if you have any system that have any value whatsoever, 03:32.000 --> 03:35.000 as some point, they will be under attack. 03:35.000 --> 03:38.000 And you will have some malware that tries to escape 03:38.000 --> 03:41.000 whatever confinement it finds itself in, 03:41.000 --> 03:45.000 whether that's your browser, and the sandbox in features it has, 03:46.000 --> 03:49.000 or whether that's a container processing 03:49.000 --> 03:51.000 and trusted data from the network. 03:51.000 --> 03:53.000 The question is, what happens after that? 03:53.000 --> 03:57.000 If malware can rotate itself, 03:57.000 --> 03:59.000 in stories that make it self persistent, 03:59.000 --> 04:01.000 then you're going to have a bad time. 04:01.000 --> 04:04.000 So, the harder that is, the better 04:04.000 --> 04:07.000 for any system where security matters. 04:07.000 --> 04:10.000 So, to not do that, 04:10.000 --> 04:13.000 there are some prerequisites, and you can use some tools 04:13.000 --> 04:15.000 that we're going to look into. 04:15.000 --> 04:18.000 But the translation here is, 04:18.000 --> 04:21.000 you really want to use a kernel verified, 04:21.000 --> 04:24.000 the n-varrity partition for your programs, 04:24.000 --> 04:26.000 so that they can be verified, 04:26.000 --> 04:28.000 cryptography by the kernel when they run. 04:28.000 --> 04:30.000 And that way, you don't just, 04:30.000 --> 04:32.000 the malware doesn't just have to escape the sandbox, 04:32.000 --> 04:35.000 doesn't just have to get execution privileges, 04:35.000 --> 04:37.000 doesn't just have to get robot, 04:37.000 --> 04:39.000 but also needs to break into the kernel 04:39.000 --> 04:41.000 and get invertible access to kernel memory. 04:41.000 --> 04:43.000 And that's hard, but impossible, 04:43.000 --> 04:44.000 but hard. 04:44.000 --> 04:45.000 And the other thing is, 04:45.000 --> 04:46.000 the more expensive it is, 04:46.000 --> 04:49.000 the less appetizing your system is for the, 04:49.000 --> 04:51.000 the bad people. 04:51.000 --> 04:54.000 Now, this is used to be really hard to do. 04:54.000 --> 04:58.000 In possible, in fact, if you have a couple years ago, 04:58.000 --> 05:00.000 but one of the purposes of particle OS 05:00.000 --> 05:03.000 is to give you the tools and the recipes 05:03.000 --> 05:07.000 to very easily create such systems and images. 05:07.000 --> 05:09.000 So, that's the motivation. 05:09.000 --> 05:11.000 Now, let's look at the tools. 05:11.000 --> 05:12.000 And because I, 05:12.000 --> 05:14.000 the system projects, 05:14.000 --> 05:15.000 image building tools, 05:15.000 --> 05:16.000 because of course, 05:16.000 --> 05:18.000 we have a image builder tool in this project. 05:18.000 --> 05:21.000 Everybody's got an image building tool. 05:21.000 --> 05:24.000 I think it's a mandatory step in any use, 05:24.000 --> 05:28.000 engineers career to write a new image building tool themselves. 05:28.000 --> 05:30.000 So, this was created by Leonard. 05:30.000 --> 05:31.000 Some years ago, 05:31.000 --> 05:34.000 to facilitate its development work for our system. 05:34.000 --> 05:36.000 These days, 05:36.000 --> 05:37.000 it's done. 05:37.000 --> 05:38.000 It's doing most of the work, 05:38.000 --> 05:40.000 maintain it together with your work. 05:40.000 --> 05:42.000 It's a python tree. 05:42.000 --> 05:43.000 Of course, 05:43.000 --> 05:45.000 it has a nice style configuration files. 05:45.000 --> 05:46.000 We love our, 05:46.000 --> 05:47.000 our, our, 05:47.000 --> 05:48.000 our config in system. 05:48.000 --> 05:49.000 As you might have read, 05:49.000 --> 05:50.000 don't I can use this, 05:50.000 --> 05:52.000 because we are Microsoft shields. 05:52.000 --> 05:54.000 So, we are by a nice files. 05:54.000 --> 05:55.000 Now, 05:55.000 --> 05:59.000 the main differentiator of these two versus all the others 05:59.000 --> 06:04.000 is that it's meant to make use of all the, 06:05.000 --> 06:07.000 fancy tools that come out of this in the project. 06:07.000 --> 06:09.000 So, the greatest and greatest stuff. 06:09.000 --> 06:11.000 And you can use it for, 06:11.000 --> 06:13.000 to build various types of images and artifacts. 06:13.000 --> 06:14.000 Now, 06:14.000 --> 06:15.000 as I mentioned, 06:15.000 --> 06:17.000 it was created for a local developer's work tools. 06:17.000 --> 06:18.000 And it's too great for that. 06:18.000 --> 06:20.000 It has some great features. 06:20.000 --> 06:21.000 And in fact, 06:21.000 --> 06:22.000 there's other projects using this. 06:22.000 --> 06:24.000 I know some kernel developers will use them 06:24.000 --> 06:26.000 because I thought they local development flows. 06:26.000 --> 06:28.000 But we have evolved it past it. 06:28.000 --> 06:31.000 And you can now use it for production images as well. 06:31.000 --> 06:33.000 You can run this on a header server. 06:33.000 --> 06:35.000 We know user interaction. 06:35.000 --> 06:38.000 All look down and it will work and build artifacts for you. 06:38.000 --> 06:41.000 And the images and build the artifacts, 06:41.000 --> 06:43.000 they are just thing to do. 06:43.000 --> 06:45.000 Always is designing. 06:45.000 --> 06:46.000 Right? 06:46.000 --> 06:50.000 So, we support two types of work tools there. 06:50.000 --> 06:53.000 The easiest one is a PCS 11-based one. 06:53.000 --> 06:56.000 So, if your build systems, 06:56.000 --> 06:58.000 security hardware, 06:58.000 --> 07:01.000 as a PCS 11 interface for signing, 07:01.000 --> 07:02.000 it's super easy. 07:02.000 --> 07:04.000 You just said that the config file, 07:04.000 --> 07:06.000 the PCS 11-URI, 07:06.000 --> 07:07.000 macOS IDOS, 07:07.000 --> 07:08.000 everything for you, 07:08.000 --> 07:10.000 and that's super nice and easy. 07:10.000 --> 07:13.000 Not all the systems do that. 07:13.000 --> 07:14.000 A lot of the systems 07:14.000 --> 07:18.000 have bespoke and custom solutions. 07:18.000 --> 07:21.000 But most of those have the same work. 07:21.000 --> 07:22.000 So, that is, 07:22.000 --> 07:23.000 you do multi-stage builds. 07:23.000 --> 07:25.000 So, if first you do your normal builds, 07:25.000 --> 07:26.000 you end up with artifacts, 07:26.000 --> 07:28.000 then your building stops. 07:28.000 --> 07:30.000 But from these artifacts, 07:30.000 --> 07:31.000 it takes hashes, 07:31.000 --> 07:32.000 sends them somewhere, 07:32.000 --> 07:34.000 and then you get back signatures of those hashes. 07:34.000 --> 07:36.000 And then you'll build the starts, 07:36.000 --> 07:37.000 and you get the artifacts, 07:37.000 --> 07:39.000 and the signatures. 07:39.000 --> 07:41.000 And instead of rebuilding your supposed to put them together again. 07:41.000 --> 07:44.000 Now, we support this for one particular build system 07:44.000 --> 07:45.000 that we talk about in a moment. 07:45.000 --> 07:46.000 But, 07:46.000 --> 07:47.000 generically, 07:47.000 --> 07:50.000 because I suppose this work was where you do the build stop, 07:50.000 --> 07:52.000 and then you can start to reattach things, 07:52.000 --> 07:54.000 like the invariant signatures, for example. 07:55.000 --> 07:57.000 Now, 07:57.000 --> 07:59.000 let's see for the tools now, 07:59.000 --> 08:02.000 what are the ingredients of this OS? 08:02.000 --> 08:03.000 Now, 08:03.000 --> 08:04.000 and what is, 08:04.000 --> 08:06.000 particularly as in practice? 08:06.000 --> 08:08.000 It's not a distribution. 08:08.000 --> 08:11.000 It is not a full-blown self-contained distribution. 08:11.000 --> 08:14.000 distribution maintainers do a tremendous difficulty, 08:14.000 --> 08:15.000 and hard, 08:15.000 --> 08:17.000 and fantastic job on maintaining two chains, 08:17.000 --> 08:19.000 and everything else on top of it. 08:19.000 --> 08:22.000 We think that the packages that the distribution builds 08:23.000 --> 08:25.000 are the right and the social layer, 08:25.000 --> 08:27.000 where to start big images from. 08:27.000 --> 08:30.000 Rather than trying to reinvent what packages do 08:30.000 --> 08:31.000 like things like, 08:31.000 --> 08:32.000 like, for example, 08:32.000 --> 08:33.000 in terms of the tools. 08:33.000 --> 08:34.000 So, 08:34.000 --> 08:36.000 particle OS is a set of recipes, 08:36.000 --> 08:40.000 and that's why the abstract has some sort of culinary team there. 08:40.000 --> 08:42.000 Because it is really just a set of recipes 08:42.000 --> 08:44.000 to take packages from distributions, 08:44.000 --> 08:46.000 and use some tools and give out these images 08:46.000 --> 08:48.000 with these particular properties. 08:48.000 --> 08:51.000 We have recipes written for Fedora, 08:51.000 --> 08:53.000 Arch-Suzen-Vebium. 08:53.000 --> 08:56.000 Any distribution supported by M. Kuzi 08:56.000 --> 08:59.000 can be trivially added. 08:59.000 --> 09:02.000 There are both speaking three categories of work 09:02.000 --> 09:06.000 you need to do in order to add a distribution to particle OS recipes. 09:06.000 --> 09:07.000 Well, first of all, 09:07.000 --> 09:10.000 particle OS has a bunch of bulletin config and roof 09:10.000 --> 09:11.000 from M. Kuzi, 09:11.000 --> 09:12.000 and we have that. 09:12.000 --> 09:14.000 The second one is list of packages, 09:14.000 --> 09:17.000 like any image building tool that is based on packages. 09:17.000 --> 09:19.000 You need to write package lists. 09:20.000 --> 09:21.000 If you do that, and then, 09:21.000 --> 09:24.000 you know, we have hooks and tools and commissionals 09:24.000 --> 09:25.000 for distribution. 09:25.000 --> 09:27.000 Version architecture and all the stuff that you expect. 09:27.000 --> 09:28.000 But yeah, 09:28.000 --> 09:31.000 you need to write the list of packages that you want in your image 09:31.000 --> 09:33.000 that is specific to your distribution. 09:33.000 --> 09:34.000 The third of the final thing is, 09:34.000 --> 09:35.000 well, work around, 09:35.000 --> 09:36.000 like, 09:36.000 --> 09:39.000 as anybody who develops image building tools knows 09:39.000 --> 09:43.000 there's always work around for these or that kind of case. 09:43.000 --> 09:45.000 In our particular situation, 09:45.000 --> 09:47.000 the main kind of work around, 09:47.000 --> 09:48.000 that we have, 09:48.000 --> 09:51.000 are for the distribution that don't support 09:51.000 --> 09:53.000 hermetic user or don't support it fully. 09:53.000 --> 09:55.000 And that's why I did a shout out 09:55.000 --> 09:56.000 beginning about that. 09:56.000 --> 09:57.000 Now, 09:57.000 --> 09:59.000 distributions are on a spectrum about that. 09:59.000 --> 10:01.000 Some are better and some are a bit worse. 10:01.000 --> 10:03.000 So there's always work around to be added. 10:03.000 --> 10:04.000 But yeah, 10:04.000 --> 10:05.000 that's the other thing. 10:05.000 --> 10:09.000 If M. Kuzi supports your package manager, 10:09.000 --> 10:10.000 then it's super easy, 10:10.000 --> 10:14.000 super trivial to add a new list or to particle OS. 10:14.000 --> 10:15.000 If it's not, 10:15.000 --> 10:17.000 like we support app, 10:17.000 --> 10:18.000 DNF, 10:18.000 --> 10:19.000 Vper Pacman, 10:19.000 --> 10:22.000 and whatever the post-market OS use, 10:22.000 --> 10:25.000 adding a new package manager is super easy, 10:25.000 --> 10:26.000 like two Python modules, 10:26.000 --> 10:29.000 and we work on PR so that. 10:29.000 --> 10:31.000 Right, so that's for the content. 10:31.000 --> 10:32.000 Now, where do we build this? 10:32.000 --> 10:35.000 Where do we use M. Kuzi to build these images? 10:35.000 --> 10:36.000 Now, 10:36.000 --> 10:38.000 every distribution has their own build system. 10:38.000 --> 10:39.000 Right. 10:39.000 --> 10:42.000 I particularly like the Susan LBS1 10:42.000 --> 10:45.000 for the OpenBus service for a few reasons. 10:45.000 --> 10:46.000 First of all, 10:46.000 --> 10:47.000 usually, 10:47.000 --> 10:51.000 a distribution of the system is only used for that distribution. 10:51.000 --> 10:54.000 You can't build a federal package or imaging at 10:54.000 --> 10:55.000 the BMB network, 10:55.000 --> 10:57.000 and vice versa. 10:57.000 --> 10:59.000 But Susan took a very different approach here, 10:59.000 --> 11:00.000 and it's very open, 11:00.000 --> 11:03.000 and it supports a ton of targets. 11:03.000 --> 11:05.000 So you can build the package. 11:05.000 --> 11:06.000 If you have packages, 11:06.000 --> 11:07.000 and arching your packages, 11:07.000 --> 11:08.000 and more, 11:08.000 --> 11:10.000 and you can build container images. 11:10.000 --> 11:12.000 Then since 2022, 11:12.000 --> 11:16.000 I have the support for M. Kuzi recipes as well. 11:16.000 --> 11:19.000 So if you upload to our OBS project, 11:19.000 --> 11:22.000 the particular recipes, 11:22.000 --> 11:24.000 it will build an image for you. 11:24.000 --> 11:27.000 So that's one of the reasons. 11:27.000 --> 11:29.000 I like this system. 11:29.000 --> 11:33.000 The other is that I particularly like 11:33.000 --> 11:36.000 how they do their signature handling and key management. 11:36.000 --> 11:39.000 Now, very often in distributions, 11:39.000 --> 11:42.000 you have first-class packages that can have access 11:42.000 --> 11:44.000 to the HSNs, 11:44.000 --> 11:47.000 to, for example, sign kernels for secure boot, 11:47.000 --> 11:49.000 and then you have their available boot. 11:49.000 --> 11:51.000 It doesn't, or as just access to some test keys 11:51.000 --> 11:53.000 that are actually public. 11:53.000 --> 11:54.000 In Susan, 11:54.000 --> 11:56.000 it's not the case in the OBS. 11:56.000 --> 11:58.000 Every single package, 11:58.000 --> 12:00.000 you'll imagine it's built on the system. 12:00.000 --> 12:03.000 From my random open source developer, 12:03.000 --> 12:06.000 account, and build things to Susan, 12:06.000 --> 12:09.000 leap or tumbleweed or microes production images, 12:09.000 --> 12:11.000 they use exactly the same sign-in code, 12:11.000 --> 12:13.000 the sign-in components, 12:13.000 --> 12:16.000 and key management strategy, and certificate management strategy. 12:16.000 --> 12:18.000 So there is a high degree of confidence 12:18.000 --> 12:19.000 that, you know, 12:19.000 --> 12:22.000 if you take the start of the dive being on the system, 12:22.000 --> 12:24.000 the project, the particular semages, 12:24.000 --> 12:29.000 it has the key management for that is done sensibly. 12:29.000 --> 12:32.000 On top of this, as a developer, 12:32.000 --> 12:34.000 that creates an image, 12:34.000 --> 12:35.000 and this is going to be, 12:35.000 --> 12:36.000 as a particular semage, 12:36.000 --> 12:38.000 I don't have access to the private keys 12:38.000 --> 12:39.000 that are used to sign that. 12:39.000 --> 12:40.000 Nobody does. 12:40.000 --> 12:42.000 The only things that get signed 12:42.000 --> 12:44.000 are the packages uploaded here in the public 12:44.000 --> 12:45.000 that you can see. 12:45.000 --> 12:47.000 So you know, if you use this, 12:47.000 --> 12:49.000 if you trust these signatures, 12:49.000 --> 12:51.000 I'm not, you know, 12:51.000 --> 12:53.000 you might act of signing with the same key, 12:53.000 --> 12:56.000 so malware that can push to your servers 12:56.000 --> 12:58.000 if they use the particular semages. 12:58.000 --> 13:01.000 And this is a very nice property that LBS gives you. 13:01.000 --> 13:03.000 Now after you build and sign then, 13:03.000 --> 13:04.000 so there's a CDN, 13:04.000 --> 13:05.000 so it's published there, 13:05.000 --> 13:07.000 the nice thing about this is that 13:07.000 --> 13:11.000 the system needs to for updating your, 13:11.000 --> 13:13.000 your OS, 13:13.000 --> 13:15.000 and the format used to publish this 13:15.000 --> 13:17.000 is supported by a set of data automatically, 13:17.000 --> 13:19.000 so it's some PGP sign-minuses, 13:19.000 --> 13:21.000 and it works out of the box, 13:21.000 --> 13:23.000 so you just point this update to it, 13:23.000 --> 13:26.000 and it will update your system as builds happen. 13:26.000 --> 13:27.000 So as mentioned, 13:27.000 --> 13:29.000 we have been in a few of these particular semages, 13:29.000 --> 13:31.000 so if you're going to link there 13:31.000 --> 13:34.000 under the system the namespace on the BS, 13:34.000 --> 13:38.000 you can download a GNOME X86 image, 13:38.000 --> 13:40.000 that are based on the 42, 13:40.000 --> 13:41.000 43, 44, 13:41.000 --> 13:43.000 the event 13 and the event 14. 13:43.000 --> 13:44.000 And also, 13:44.000 --> 13:45.000 yeah, our images, 13:45.000 --> 13:46.000 um, 13:46.000 --> 13:47.000 um, 13:47.000 --> 13:48.000 64 for the event 13 and 14. 13:48.000 --> 13:50.000 I use that on my Raspberry Pi for some, 13:50.000 --> 13:51.000 all automation. 13:51.000 --> 13:52.000 Um, 13:52.000 --> 13:55.000 so anybody can go download this and use them, 13:55.000 --> 13:56.000 and try them now, 13:56.000 --> 13:58.000 VM or hardware or whatever else. 13:58.000 --> 13:59.000 Um, 13:59.000 --> 14:01.000 define a great thing about this system, 14:01.000 --> 14:02.000 this bit system, 14:02.000 --> 14:04.000 and why it's the way for particularly my opinion, 14:04.000 --> 14:06.000 is that users can, 14:06.000 --> 14:07.000 um, 14:07.000 --> 14:08.000 just, 14:08.000 --> 14:10.000 for the images that I'm building there, 14:10.000 --> 14:12.000 and get them under their own project, 14:12.000 --> 14:15.000 and then they get signed by their own project keys, 14:15.000 --> 14:16.000 instead of mine, 14:16.000 --> 14:18.000 and they can be even customized. 14:18.000 --> 14:20.000 Now, I wanted to show the page how this looks like, 14:20.000 --> 14:22.000 I don't trust the networks like a screenshot. 14:22.000 --> 14:23.000 I hope it's visible. 14:23.000 --> 14:24.000 Um, 14:24.000 --> 14:25.000 um, but basically, 14:25.000 --> 14:26.000 this is the particulars, 14:26.000 --> 14:27.000 fedora, 14:27.000 --> 14:28.000 be good on the BS. 14:28.000 --> 14:29.000 On the left and side, 14:29.000 --> 14:30.000 if you're signing in any, 14:30.000 --> 14:31.000 any open source that they're working signing in, 14:31.000 --> 14:32.000 and get an account, 14:32.000 --> 14:34.000 you click on the branch package there, 14:34.000 --> 14:36.000 and this will get copied, 14:36.000 --> 14:37.000 you know, 14:37.000 --> 14:38.000 the configuration under your own project. 14:38.000 --> 14:41.000 So it gets signed by your own certificate, 14:41.000 --> 14:43.000 instead of mine under this namespace, 14:43.000 --> 14:44.000 and, 14:44.000 --> 14:45.000 uh, 14:45.000 --> 14:46.000 so you have a different arse chain. 14:46.000 --> 14:47.000 And then, 14:47.000 --> 14:48.000 if you click, 14:48.000 --> 14:49.000 the underscore service file, 14:49.000 --> 14:50.000 it's visible there. 14:50.000 --> 14:51.000 Well, basically, 14:51.000 --> 14:52.000 that's where it's an XML, 14:52.000 --> 14:55.000 that defines the iteratively points to. 14:55.000 --> 14:57.000 So you can then build your own version of a particular 14:57.000 --> 14:59.000 as customizing your recipes, 14:59.000 --> 15:00.000 and this is that simple. 15:00.000 --> 15:02.000 You just push it to a bit repository, 15:02.000 --> 15:03.000 uh, 15:03.000 --> 15:04.000 click branch, 15:04.000 --> 15:05.000 change the service file to point to your repo, 15:05.000 --> 15:07.000 and you get images, 15:07.000 --> 15:10.000 which is pretty awesome if you ask me. 15:10.000 --> 15:11.000 Um, 15:11.000 --> 15:12.000 now, 15:12.000 --> 15:14.000 what is the end result? 15:14.000 --> 15:15.000 Uh, 15:15.000 --> 15:16.000 why do we want this thing? 15:16.000 --> 15:17.000 Uh, 15:17.000 --> 15:18.000 what are the tools? 15:18.000 --> 15:19.000 How do we put it together? 15:19.000 --> 15:20.000 And where? 15:20.000 --> 15:21.000 What is the end result? 15:21.000 --> 15:23.000 How do we get out of this? 15:23.000 --> 15:24.000 Um, 15:24.000 --> 15:25.000 so first of all, 15:25.000 --> 15:27.000 you get a UFS, 15:27.000 --> 15:28.000 um, 15:28.000 --> 15:29.000 for the system, 15:29.000 --> 15:30.000 for the accusatory, 15:30.000 --> 15:31.000 um, 15:31.000 --> 15:32.000 signed, 15:32.000 --> 15:33.000 protected by sign, 15:33.000 --> 15:34.000 the severity, 15:34.000 --> 15:36.000 and it's based on federal art, 15:36.000 --> 15:37.000 social, 15:37.000 --> 15:38.000 they're depending on what you build. 15:38.000 --> 15:39.000 For your BSB, 15:39.000 --> 15:40.000 this federal, 15:40.000 --> 15:41.000 they're being, 15:41.000 --> 15:42.000 um, 15:42.000 --> 15:43.000 you can of course be the local, 15:43.000 --> 15:44.000 and then you can choose other, 15:44.000 --> 15:45.000 other combinations. 15:45.000 --> 15:46.000 Um, 15:46.000 --> 15:47.000 and then the image, 15:47.000 --> 15:48.000 we also have, 15:48.000 --> 15:50.000 um, 15:50.000 --> 15:52.000 and you can assign UKI. 15:52.000 --> 15:53.000 And so this two, 15:53.000 --> 15:55.000 a partitioner combine in a GPT image, 15:55.000 --> 15:56.000 um, 15:56.000 --> 15:58.000 so I'll fill with this color of this image. 15:58.000 --> 15:59.000 And then, 15:59.000 --> 16:00.000 um, 16:00.000 --> 16:01.000 you can run this in, 16:01.000 --> 16:03.000 system IVM spawn, 16:03.000 --> 16:04.000 or N spawn, 16:04.000 --> 16:05.000 or QMU, 16:05.000 --> 16:06.000 or Bermetal, 16:06.000 --> 16:08.000 and what happens at the first boot, 16:08.000 --> 16:09.000 um, 16:09.000 --> 16:10.000 system D, 16:10.000 --> 16:12.000 we'll format the, 16:12.000 --> 16:13.000 um, 16:13.000 --> 16:14.000 the root, 16:14.000 --> 16:15.000 for the system, 16:15.000 --> 16:16.000 um, 16:16.000 --> 16:17.000 the home, 16:17.000 --> 16:19.000 for the system, 16:19.000 --> 16:20.000 and again, 16:20.000 --> 16:21.000 the TPM2, 16:21.000 --> 16:22.000 the local TPM2. 16:22.000 --> 16:23.000 Um, 16:23.000 --> 16:24.000 so you got, 16:24.000 --> 16:25.000 um, 16:25.000 --> 16:27.000 lots to encrypt the partitions there. 16:27.000 --> 16:28.000 Um, 16:28.000 --> 16:29.000 so then you can also have, 16:29.000 --> 16:30.000 system D, 16:30.000 --> 16:31.000 this is update, 16:31.000 --> 16:32.000 um, 16:32.000 --> 16:33.000 configuration, 16:33.000 --> 16:35.000 and again, 16:35.000 --> 16:36.000 points of the BS, 16:36.000 --> 16:38.000 if you download the images from the BS. 16:38.000 --> 16:39.000 So, 16:39.000 --> 16:40.000 uh, 16:40.000 --> 16:41.000 as new beings happen, 16:41.000 --> 16:42.000 um, 16:42.000 --> 16:43.000 so BS automatically will be, 16:43.000 --> 16:44.000 when the penises changes, 16:44.000 --> 16:45.000 for example. 16:45.000 --> 16:46.000 So, 16:46.000 --> 16:47.000 your system, 16:47.000 --> 16:48.000 we automatically get updated. 16:48.000 --> 16:49.000 So, 16:49.000 --> 16:50.000 we'll decide when it runs, 16:50.000 --> 16:51.000 and you can also, 16:51.000 --> 16:52.000 how to reboot if you want, 16:52.000 --> 16:53.000 that's something you can configure. 16:53.000 --> 16:54.000 Um, 16:54.000 --> 16:56.000 it uses an AB partition in skin, 16:56.000 --> 16:57.000 so it will install, 16:57.000 --> 16:58.000 um, 16:58.000 --> 16:59.000 the new version in the, 16:59.000 --> 17:00.000 in the free space, 17:00.000 --> 17:01.000 in the free partition, 17:01.000 --> 17:02.000 in the unused partition, 17:02.000 --> 17:04.000 and then it will use something similar 17:04.000 --> 17:05.000 to the previous talk, 17:05.000 --> 17:06.000 so boot assessment, 17:06.000 --> 17:07.000 um, 17:07.000 --> 17:08.000 if the boot phase, 17:08.000 --> 17:09.000 we automatically, 17:09.000 --> 17:10.000 for back to the previous one, 17:10.000 --> 17:11.000 um, 17:11.000 --> 17:12.000 it will also use, 17:12.000 --> 17:13.000 HomeD, 17:13.000 --> 17:14.000 um, 17:14.000 --> 17:15.000 for user, 17:15.000 --> 17:17.000 and, 17:18.000 --> 17:19.000 so we have known, 17:19.000 --> 17:20.000 uh, 17:20.000 --> 17:21.000 favels, 17:21.000 --> 17:22.000 and KD, 17:22.000 --> 17:23.000 uh, 17:23.000 --> 17:24.000 favels as well. 17:24.000 --> 17:25.000 We have the recipe for that. 17:25.000 --> 17:26.000 I don't be that obvious, 17:26.000 --> 17:27.000 nobody asked for it. 17:27.000 --> 17:28.000 Um, 17:28.000 --> 17:29.000 but it's there. 17:29.000 --> 17:30.000 You can be the locally, 17:30.000 --> 17:31.000 but both of these, 17:31.000 --> 17:32.000 if you build these favels, 17:32.000 --> 17:34.000 then they will come with the, 17:34.000 --> 17:35.000 flat up in your wallet, 17:35.000 --> 17:36.000 because, 17:36.000 --> 17:37.000 of course, 17:37.000 --> 17:38.000 your, 17:38.000 --> 17:39.000 uh, 17:39.000 --> 17:40.000 window three is the only, 17:40.000 --> 17:42.000 you cannot add stuff. 17:42.000 --> 17:43.000 Um, 17:43.000 --> 17:44.000 the idea with this is that, 17:44.000 --> 17:46.000 the way to add new software is, 17:47.000 --> 17:48.000 um, you can download, 17:48.000 --> 17:49.000 a flat, 17:49.000 --> 17:50.000 self-packification from startup, 17:50.000 --> 17:51.000 so it's already enabled, 17:51.000 --> 17:53.000 but it's for the front-level deposit, 17:53.000 --> 17:54.000 to a configured. 17:54.000 --> 17:55.000 Um, 17:55.000 --> 17:56.000 if it's a server, 17:56.000 --> 17:57.000 then use your stuff, 17:57.000 --> 17:58.000 you know, 17:58.000 --> 17:59.000 you have containers, 17:59.000 --> 18:00.000 you have portable services, 18:00.000 --> 18:01.000 which are awesome. 18:01.000 --> 18:02.000 Um, 18:02.000 --> 18:03.000 you have, 18:03.000 --> 18:04.000 you have, 18:04.000 --> 18:05.000 um, 18:05.000 --> 18:06.000 these are books, 18:06.000 --> 18:07.000 or whatever you want. 18:07.000 --> 18:09.000 Now, 18:09.000 --> 18:11.000 the fun I think, 18:11.000 --> 18:12.000 um, 18:12.000 --> 18:14.000 that's quite important for the next slide, 18:14.000 --> 18:15.000 is that the UKIs, 18:15.000 --> 18:17.000 also come with profile, 18:17.000 --> 18:19.000 so UKIs can have multiple profiles 18:19.000 --> 18:21.000 that you can choose to boot into. 18:21.000 --> 18:22.000 And one of those, 18:22.000 --> 18:25.000 as the IPSM enabled with the policy, 18:25.000 --> 18:28.000 IP stands for Integrity Policy Enforcement, 18:28.000 --> 18:29.000 and it's a new Linux system, 18:29.000 --> 18:30.000 you know, 18:30.000 --> 18:33.000 security module that Microsoft added to the kernel last year. 18:33.000 --> 18:34.000 And, 18:34.000 --> 18:35.000 why is it important? 18:35.000 --> 18:36.000 Well, 18:36.000 --> 18:37.000 because, 18:37.000 --> 18:38.000 when I saw the total calculus, 18:38.000 --> 18:39.000 um, 18:39.000 --> 18:41.000 chatting about the security model of this, 18:41.000 --> 18:42.000 and how we want to impose security, 18:42.000 --> 18:44.000 and this is how we do it. 18:44.000 --> 18:46.000 What you end up at the end, 18:46.000 --> 18:47.000 is that, 18:47.000 --> 18:50.000 if security boot is enabled on the system, 18:50.000 --> 18:51.000 in set up mode, 18:51.000 --> 18:52.000 when you first boot, 18:52.000 --> 18:53.000 a particular image, 18:53.000 --> 18:56.000 it will self-enroll the certificates, 18:56.000 --> 18:59.000 that are used to sign the, 18:59.000 --> 19:00.000 the, 19:00.000 --> 19:02.000 the images on the BS, 19:02.000 --> 19:04.000 so that security boot is automatically enabled. 19:04.000 --> 19:05.000 Um, 19:05.000 --> 19:06.000 so then you have the user, 19:06.000 --> 19:07.000 the chain of tasks, 19:07.000 --> 19:09.000 so the CPU verifies the firmware, 19:09.000 --> 19:11.000 the firmware verifies system reboot, 19:11.000 --> 19:13.000 as the boot verifies the UKIs, 19:13.000 --> 19:14.000 using the firmware again, 19:14.000 --> 19:16.000 and the UKI contains the kernel, 19:16.000 --> 19:18.000 which at this point is verified as well, 19:18.000 --> 19:19.000 because it was contained in the UKI, 19:19.000 --> 19:21.000 and then the new thing in the kernel, 19:21.000 --> 19:24.000 then verifies the vendor tree, 19:24.000 --> 19:26.000 because it's a sign-in, 19:26.000 --> 19:27.000 very typical, 19:27.000 --> 19:28.000 not just the invariable sign, 19:28.000 --> 19:30.000 and the signature is part of the, 19:30.000 --> 19:31.000 uh, 19:31.000 --> 19:32.000 GPT partition table, 19:32.000 --> 19:33.000 using the DDI, 19:33.000 --> 19:35.000 discovered this image of scheme. 19:35.000 --> 19:38.000 And that means the kernel trusts your vendor tree, 19:38.000 --> 19:40.000 and as proof that is genuine, 19:40.000 --> 19:42.000 because the certificate is the same, 19:42.000 --> 19:44.000 and there was used to sign everything else, 19:44.000 --> 19:45.000 because we have all, 19:45.000 --> 19:46.000 um, 19:46.000 --> 19:47.000 the, 19:47.000 --> 19:48.000 the same keys, 19:48.000 --> 19:49.000 and then they get, 19:49.000 --> 19:50.000 pass down to the kernels, 19:50.000 --> 19:51.000 um, 19:51.000 --> 19:53.000 machine and platform keyrings. 19:53.000 --> 19:54.000 Um, 19:54.000 --> 19:55.000 at that point, 19:55.000 --> 19:56.000 uh, 19:56.000 --> 19:57.000 if you have the IP, 19:57.000 --> 19:58.000 the integrated-positive, 19:58.000 --> 19:59.000 uh, 19:59.000 --> 20:00.000 enforcement LSM, 20:00.000 --> 20:01.000 with opposing the inter-D, 20:01.000 --> 20:02.000 that is signed, 20:02.000 --> 20:03.000 then we get loaded by system-D, 20:03.000 --> 20:04.000 and at that point, 20:04.000 --> 20:05.000 the kernel, 20:05.000 --> 20:07.000 we verify that every single binary, 20:07.000 --> 20:08.000 or library, 20:08.000 --> 20:10.000 that gets loaded for execution on the system, 20:11.000 --> 20:12.000 comes from a sign, 20:12.000 --> 20:14.000 the invariant image that it trusts. 20:14.000 --> 20:15.000 If it doesn't, 20:15.000 --> 20:16.000 it will reject, 20:16.000 --> 20:17.000 um, 20:17.000 --> 20:18.000 execution. 20:18.000 --> 20:20.000 So what this gives you, 20:20.000 --> 20:21.000 uh, 20:21.000 --> 20:22.000 is an end-dwind, 20:22.000 --> 20:23.000 immutable, 20:23.000 --> 20:24.000 and cryptographic, 20:24.000 --> 20:25.000 verified, 20:25.000 --> 20:26.000 chain-of-trust, 20:26.000 --> 20:28.000 the status of the hardware, 20:28.000 --> 20:29.000 and compasses, 20:29.000 --> 20:30.000 everything, 20:30.000 --> 20:31.000 only way, 20:31.000 --> 20:32.000 including your user-space software. 20:32.000 --> 20:33.000 Um, 20:33.000 --> 20:34.000 now, 20:34.000 --> 20:35.000 this is not complete, 20:35.000 --> 20:36.000 right? 20:36.000 --> 20:37.000 This is working progress. 20:37.000 --> 20:38.000 Um, 20:38.000 --> 20:39.000 for example, 20:39.000 --> 20:41.000 now Microsoft is the interpreter scripts. 20:41.000 --> 20:42.000 Uh, 20:42.000 --> 20:44.000 IP currently covers only binaries. 20:44.000 --> 20:45.000 Um, 20:45.000 --> 20:46.000 if you do bash some scripts, 20:46.000 --> 20:47.000 then you cannot verify that. 20:47.000 --> 20:48.000 But, 20:48.000 --> 20:49.000 um, 20:49.000 --> 20:50.000 the kernel of the algorithm, 20:50.000 --> 20:51.000 um, 20:51.000 --> 20:52.000 API, 20:52.000 --> 20:53.000 implemented anywhere else. 20:53.000 --> 20:54.000 Uh, 20:54.000 --> 20:55.000 I think other colleagues, 20:55.000 --> 20:56.000 um, 20:56.000 --> 20:57.000 in NS are trying to, 20:57.000 --> 21:00.000 uh, 21:00.000 --> 21:02.000 get the first interpreters enlightened, 21:02.000 --> 21:04.000 but the end goal for Microsoft is to be able to run, 21:04.000 --> 21:05.000 this, 21:05.000 --> 21:06.000 uh, 21:06.000 --> 21:07.000 kind of images on servers, 21:08.000 --> 21:09.000 um, 21:09.000 --> 21:11.000 about people cannot run any kind of code. 21:11.000 --> 21:12.000 Um, 21:12.000 --> 21:13.000 the other thing that would be good to do, 21:13.000 --> 21:14.000 not for Microsoft, 21:14.000 --> 21:15.000 but for, 21:15.000 --> 21:16.000 another, 21:16.000 --> 21:17.000 with another hat on, 21:17.000 --> 21:18.000 is to make GNOME, 21:18.000 --> 21:19.000 uh, 21:19.000 --> 21:20.000 IP-friendly. 21:20.000 --> 21:21.000 I know it isn't because of the JavaScript, 21:21.000 --> 21:22.000 uh, 21:22.000 --> 21:23.000 and the JavaScript stuff of the UI. 21:23.000 --> 21:24.000 Um, 21:24.000 --> 21:25.000 so I would really love to be able to make, 21:25.000 --> 21:26.000 um, 21:26.000 --> 21:27.000 make it possible to boot, 21:27.000 --> 21:28.000 like GNOME profile, 21:28.000 --> 21:29.000 um, 21:29.000 --> 21:30.000 uh, 21:30.000 --> 21:31.000 with IP enabled, 21:31.000 --> 21:32.000 but right now it's not possible. 21:32.000 --> 21:33.000 Um, 21:33.000 --> 21:34.000 right. 21:34.000 --> 21:35.000 Now, 21:35.000 --> 21:36.000 I have four minutes left. 21:36.000 --> 21:37.000 I have two demos, 21:37.000 --> 21:38.000 but they're recorded. 21:38.000 --> 21:39.000 Um, 21:39.000 --> 21:41.000 so they can be watched online. 21:41.000 --> 21:43.000 I actually prefer to do questions or comments, 21:43.000 --> 21:44.000 if there are, 21:44.000 --> 21:45.000 um, 21:45.000 --> 21:46.000 in the last four minutes. 21:46.000 --> 21:47.000 Please. 21:47.000 --> 21:48.000 Is that key, 21:48.000 --> 21:49.000 compatible with platforms? 21:49.000 --> 21:50.000 No. 21:50.000 --> 21:51.000 That is another thing we need to do. 21:51.000 --> 21:52.000 Uh, 21:52.000 --> 21:53.000 first GNOME is to be compatible with that. 21:53.000 --> 21:54.000 Sorry. 21:54.000 --> 21:55.000 The question was, 21:55.000 --> 21:57.000 is IP compatible with that pack? 21:57.000 --> 21:58.000 And the answer is not yet. 21:58.000 --> 22:00.000 So first we need to get GNOME to work with, 22:00.000 --> 22:01.000 uh, 22:01.000 --> 22:02.000 call integrity and the problem is, 22:02.000 --> 22:03.000 uh, 22:03.000 --> 22:04.000 uh, 22:04.000 --> 22:06.000 and then platform uses 22:06.000 --> 22:07.000 tables, 22:07.000 --> 22:08.000 um, 22:08.000 --> 22:09.000 tables are not great. 22:09.000 --> 22:10.000 Um, 22:10.000 --> 22:11.000 for integrity protection. 22:11.000 --> 22:12.000 So, 22:12.000 --> 22:13.000 no, 22:13.000 --> 22:14.000 it doesn't, 22:14.000 --> 22:15.000 um, 22:15.000 --> 22:16.000 we have some chats with some people. 22:16.000 --> 22:17.000 It would be great if 22:17.000 --> 22:18.000 flat pack did, 22:18.000 --> 22:19.000 um, 22:19.000 --> 22:20.000 signed the invited for there. 22:20.000 --> 22:21.000 Uh, 22:21.000 --> 22:23.000 images, 22:23.000 --> 22:25.000 and then it would work out of the box, 22:25.000 --> 22:26.000 but it doesn't ring out. 22:26.000 --> 22:28.000 And there are no concrete plans that I know of, 22:28.000 --> 22:29.000 to do that. 22:29.000 --> 22:30.000 It would be great if they were. 22:30.000 --> 22:31.000 Yes. 22:32.000 --> 22:36.000 So the question is, 22:36.000 --> 22:38.000 with water at what point of the, 22:38.000 --> 22:39.000 um, 22:39.000 --> 22:40.000 provisioning, 22:40.000 --> 22:41.000 do you do the enrollment of the, 22:41.000 --> 22:43.000 of the keys that are used on a BS? 22:43.000 --> 22:44.000 Um, 22:44.000 --> 22:45.000 the answer is, 22:45.000 --> 22:46.000 um, 22:46.000 --> 22:47.000 on boot, 22:47.000 --> 22:48.000 um, 22:48.000 --> 22:49.000 by system boot. 22:49.000 --> 22:50.000 So when the, 22:50.000 --> 22:51.000 you boot on a system, 22:51.000 --> 22:52.000 uh, 22:52.000 --> 22:53.000 as I mentioned, 22:53.000 --> 22:54.000 secure boot needs to be enabled, 22:54.000 --> 22:55.000 but in stat mode. 22:55.000 --> 22:57.000 And then that means system D can still boot. 22:57.000 --> 22:58.000 Um, 22:59.000 --> 23:01.000 the ESP contains under the loader, 23:01.000 --> 23:02.000 or slash auto, 23:02.000 --> 23:03.000 no, 23:03.000 --> 23:04.000 orders, 23:04.000 --> 23:05.000 loader, 23:05.000 --> 23:06.000 slash key, 23:06.000 --> 23:07.000 auto directory. 23:07.000 --> 23:08.000 Um, 23:08.000 --> 23:09.000 the, 23:09.000 --> 23:10.000 the certificates in the format that, 23:10.000 --> 23:11.000 uh, 23:11.000 --> 23:12.000 you feel understands. 23:12.000 --> 23:13.000 And then it will self-ahold them. 23:13.000 --> 23:14.000 So it's that point. 23:14.000 --> 23:15.000 And then from there, 23:15.000 --> 23:17.000 they get percolated all the way down to the kernel, 23:17.000 --> 23:20.000 because the kernel picks up keys in the db, 23:20.000 --> 23:21.000 in the db, 23:21.000 --> 23:24.000 and puts them into the machine gear. 23:24.000 --> 23:26.000 Any other question? 23:26.000 --> 23:28.000 Yes. 23:28.000 --> 23:30.000 So how many years are you having? 23:30.000 --> 23:31.000 So I mean, 23:31.000 --> 23:32.000 the question was, 23:32.000 --> 23:34.000 how many users do I have? 23:34.000 --> 23:35.000 Um, 23:35.000 --> 23:37.000 I have one user at home, 23:37.000 --> 23:39.000 who doesn't know about it? 23:39.000 --> 23:40.000 That is my partner, 23:40.000 --> 23:42.000 on the laptop. 23:42.000 --> 23:44.000 Uh, 23:44.000 --> 23:46.000 So I'm willing user there. 23:46.000 --> 23:47.000 Um, 23:47.000 --> 23:48.000 and in fact, 23:48.000 --> 23:52.000 like, 23:52.000 --> 23:54.000 like, 23:54.000 --> 23:59.480 Sorry, but yes, and then I think let not as one lap to the use it 23:59.800 --> 24:03.320 Might as a very par use it then as a node lap to the use it 24:04.480 --> 24:07.440 I don't know we more users. Yes, please go and use this 24:07.760 --> 24:13.080 It will it will only break your toaster and your goal vision your cat if you do, but it's going to be fun 24:14.000 --> 24:20.480 Now most in the speaking Microsoft uses this technology is in their own in our own Azure infrastructure 24:20.480 --> 24:23.760 It's not particularly as but it's the same stuff with the American IP and so on so forth 24:24.960 --> 24:26.960 Get question 24:27.280 --> 24:29.280 30 seconds 24:29.280 --> 24:33.680 Any more question as 25 seconds. Yes, where are you using this at Microsoft? 24:34.040 --> 24:35.280 So 24:35.280 --> 24:42.040 Part of the question was where do we use this as Microsoft the answer is we don't use particle S it's to new 24:42.400 --> 24:47.480 We use the severity sign the severity and IP and that is in the Azure infrastructure 24:47.480 --> 24:50.160 So various components of the Azure infrastructure the run Linux 24:50.160 --> 24:55.000 One of which is called Azure boost which is what I do as my day job is a harder Linux 24:55.000 --> 24:57.000 Parting system and use