 So, if I had known, I might not have cut so many slides from my deck last night. A lot has been going on in the Linux integrity subsystem, but it's not only the integrity subsystem, but it affects a number of different subsystems, and we'll get to the different subsystems that we're talking about. And before I begin, I'd like to thank everybody who's reviewed patches, who's submitted patches, and who's been involved in the process, the general process, of getting the substream. It's obviously not only me, it's everyone here and those people that are not here. And as we go through, I'll include their name. You'll see different people that have been involved in the process. So every year we start out with closing the measurement appraisal gaps. And we're going to continue that. And I normally end with where we are and what needs to be done still. And I'll do that in the kernel, but from what I understand, I've been supplanted by Dave and that Dave is going to be doing the measurement gaps throughout what still needs to be done. So David Howells is the maintainer for the key ring subsystem. And unfortunately, he's not here to tell you about the changes that have gone in. From I'm going to be talking about those changes that have affected the integrity subsystem. And then we'll continue along with a couple of other things. Okay. So starting from closing measurement gaps, the first thing that we did was there were different security hooks for appraising, well, there were different security hooks that were being used for different things. And they're called the pre hooks and the post hooks for firmware and kernel modules. And everybody is trying to do the same thing. They want to be in those places at the time that they need to do something like appraise the file signatures, see what file system it's on, and so on. And of course doing mandatory access control like SMAC and SE Linux. So instead of having everybody reading their, having their own version of opening a file, reading the file, and having the security hooks around it, we then, we replaced all of those and it was a major effort because it touched basically six subsystems. And so with that case's help and with that Lewis who was driving the work, it couldn't have been done as quickly or as fast. Once we had the replacement, then other things can actually use the same method of using the same pre and post security hooks. The first one, well, the second one was AIMA where you're trusting the system based on a certain policy, but we don't, and we cat in that policy. So instead of trusting the policy, we now use the same mechanism throughout that we've used for appraising kernel modules and firmware and other things. We're now able to verify the signature on the AIMA policy. You boot up with a built-in policy and then you transition to another policy and that policy can now be signed. And then we used it for Kexec, Eric Richter is going to be speaking later this afternoon about Kexec and how they're using it for Petty Boot. But basically the things that we did there were now we can, when you're using, when you do Kexec, which is a soft reboot, you can now appraise the measurement of the kernel that's going to be run. And you can appraise then at RAMFS. Both of them are still used from an AIMA perspective. They're both using AIMA signatures. Other work in this, so Eric will be talking about allowing, since this is going to be in the early boot process, we're not going to be wanting to use just the AIMA PCRs, but we want the option to be adding these measurements in different PCRs. And I assume that most everyone knows about TPMs and PCRs here, so I'm not going to backtrack and describe what a PCR is. So that was upstreamed earlier this year, where we can now appraise the signature on the RAMFS and the image. The same hook that's used for appraising can be used for measuring. The only problem is it doesn't make sense to measure it unless you can carry it across Kexec. You'll have it in the measurement list for a couple of seconds, and then poof, it's gone. So a lot of the work that we're currently doing is to be able to carry the measurement list across Kexec. And that work is being done by a number of people, including Tiago Bowerman. And as of last night, Andrew accepted his patches into the mmTree. At the point where, and they're waiting for my patches to make it into the mmTree at this point, he takes it and he works on the device tree. My patches for actually doing the serializing and the restoring of the measurement list have another round or two to make it through the mailing list. Basically, I didn't realize that we can boot a, that the system that's running can be in one endianess and it can be, can be booting a different image in a different endianess. And so we had to serialize, we had to canonize the format that's being used so that each of them would be able to understand the previous measurement list. So the other, while we're in the Kexec, everybody says the boot command line is really important. You really need to measure the boot command line. If you don't measure it, you might be measuring all your applications, but you have left out a major piece of information. And so we have some patches that have been posted once that still need to be revisited. But the first question is, okay, we can measure the boot command line, but are we ever going to want to be able to sign it? And if we do, before we upstream just the measurement, maybe it's time to talk about a method of signing buffer measurements, as I'm referring to them here. And those buffer measurements, so we had, with Kexec, I'm sorry, with kernel modules, we have the idea of an attached signature. Do we want it in the same, similarly, to kernel modules where it's an attached signature, or would we want it as a detached signature? And those are still questions that we're going to be seeing what the community decides is necessary. And there's one more thing that's not showing up on the slide. And it's probably down at the bottom here, not showing. The last thing is, the other thing that needs to be worked on is the CPIO in RAMFS. And the CPIO in RAMFS, I was thinking that it could be simplified, but as I've been working, we've had some time to talk and hallway designs with Victor. And his use case, with having to deal with sim links, won't allow it to be, won't allow it, I don't think that we're going to be able to simplify it. But it looks like it's coming, it will be around soon. Okay, so now that we have a single method of being able to appraise and measure different things that are being read by the kernel, we need to go through and see what things should be using it. And we know that there are policies, I think that there's a smack policy that might be involved, there might be an SC Linux policy that should be converting over to using this method. They're not currently using files, they're not reading files, they're basically, as far at least Casey will correct me if I'm wrong, the policy is being catted into a security FS, I know for SC Linux that's the current method. But maybe we need to start appraising the policies themselves. The other thing is that before somebody starts to use, starts to write their own method of reading a file from the kernel, we need another mechanism to say, hey, maybe you should be using kernel read file. And I'm now working with Julia to maybe get that in to tag it so that we don't come up with another method, another way of doing things, again, that we're not on the hooks, that we don't have the security hooks for. Okay. And before, we said that one of the issues was BPF, and we've said that they're safe, that at least the original ones were safe, but now we're seeing a lot of the talks here at LinuxCon, we're using new ways of using BPF. And the question is, do they, is it, and especially the EBPF, which, the extended BPF. So I'm not sure exactly how we allowed another Cisco to be upstreamed that doesn't have a file descriptor. We went through a lot of effort to change kernel modules and to change the firmware loading to have a file descriptor. And now all of a sudden we have a new one that doesn't have a file descriptor. So I guess I was kind of sleeping on that. In terms of the key ring changes, as I said, this is not a complete set of changes what has gone in, and key rings that's really up to David House to be giving a talk on that. But in terms of IMA, we now have, we first, we started this conversation from last year's talk, Petko Manilov and Mark came and talked about Juniper's requirements. And it fed into that they needed an intermediary key ring, which is referred to the mock key ring. And they needed a blacklist. And we started up streaming that. It actually was upstreamed. And then we were able to, David was able to generalize it. And he generalized the concept by saying, okay, instead of it just being at the IMA level, it's now at the system level. It's at a global level. So the asymmetric keys can now be restricted by a signature. And we can say which signature. So when, if everybody has, is aware of the system key ring that we, that there are built-in keys that gets loaded onto the system, onto the system key ring, and the restrict link. So we now rename the system key ring to the built-in key ring. And the only thing on that key ring is the built-in keys. And so this provides us a signature chain of trust all the way from the boot, from UEFI secure boot, all the way up to the running of the system. And we transition when we boot into this trusted key ring. And last year, Petco and Mark were talking about needing a secondary. And so instead of calling it a mock, we now have, it can be trusted based on either the secondary key ring or based on the built-in key ring. Okay, the black list there are some issues with. It's still in an experimental stage. And we're looking at how to do this properly at the global level. So it hasn't transitioned from the IMA, from an IMA key ring into the global. So now once we've done that, and we have the built-in key ring, and we can trust it, we can now transition to user space. And user space says, hey, I need a key that is extended from all the way from UEFI secure boot to the kernel, and then from the kernel, transitions from the kernel into user space. And so, and this is being done by Matt. Matt, if you're here, you can raise your hand. And I'm really excited about this for being able to extend the secure route of trust all the way up to this secure signature chain of trust all the way up into user space. As it turns out, Matt's initial reason for wanting this is that he wanted to be able to use an independent key ring, but have the same semantics as the built-in key ring. And he wanted to say, this set of keys are authorized to add keys. This key or this set of keys is allowed to add keys to another key ring. And only those keys will be used to do whatever he was doing for whatever his application. But from my point of view, the other is more exciting and more interesting. And so I'm hoping to be able to say next year that this has been accomplished. In terms of my group, the biggest problem with appraising things is that you need signatures. Without signatures, nobody can really be doing appraisal. And so everybody is stuck at the step of having to sign it on their own and having to roll their own kernel and do everything on their own. So we went through and set up mirrors. Ubuntu and Red Hat mirrors, sorry, Fedora mirrors. And right now, we have the internal part done. We do not have the external mirror up and running yet. But the idea is that the IBM processing is opening up the packages, adding the signatures into them, and then closing it back up so that you can do your DNF, your AppGat or whatever you're using to update the packages. And so that you don't have a post-install process of having to sign it. The problem with this is that it would be really nice for the distros to start signing their code for anybody who's writing code to be including the file signatures. We now have TAR support. We have RPM support and we're working on Debian to get it upstreamed. There are, Debian includes it as a TAR and we'll see if there were other mechanisms for getting the signatures in the Debian packages. But right now, we're using a TAR implementation for including them. So even if the distros started including file signatures, you might want to run your own code. So we need a way of adding a certificate into the running system onto the built-in key ring. And Mehmed Caleb of our group has done the work for reserving memory that will be for the built-in key ring. And if you can enable this on your system, then you can install a key. And obviously you'll have to post, you'll have to re-sign the kernel image, but at least you don't have to rebuild the kernel image. And this is one way of getting the key onto the built-in key ring. It's also a way for product development to be able to build a single kernel that will later have different keys depending on at what stage they are in the process of development. Okay, so we now have come up to that we are closing all these measurement gaps and appraisals, but there's a problem left. And the problem is that if we go back to the previous slide, we've added one key per distro. But do we really want it at that level? And before we even finished going forward and having this all set up, there was a comment on the summit mailing list saying that we want to do it not at the distro level, not at the package level. We want to verify it based on a path name key. So I'm happy that we're getting closer and closer to being able to appraise everything and measure everything. But the next question is going to be at what level of granularity do we need to support this? And the finer the granularity that have, the less that will have to be revoked. The less, if it's at a package level, the less packages that will be affected on for revoking if something should needs to be replaced. So we definitely need the support that we spoke about before about the black lists so that we can revoke keys as going forward. And instead of having each thing that's trying to appraise their measurements, have their own method of doing it, let's try to work like firmware. Okay, it might be path name based. But the same method, the same requirements are going to come up again. And so let's try to do, have a common way of doing it. So that everybody can take advantage of it for their use case. Okay, so now we're, wow. Okay, so we'll quickly sum up. What we have here is that with TPM 2.0, it impacts IMA. IMA is still based on TPM 1.2, and it's extending the SHA-1 bank. A lot of the servers, a lot of the machines are now starting to come out with TPM 2.0, and they're enabling the SHA-256 bank. Some of them have both a SHA-1 bank and a SHA-256 bank enabled. Some of them do, some of them don't. So the question is, how do we transition to this? Are we going to start adding multiple hashes? Is IMA going to hash it twice? Or are we going to include the larger digest in the measurement list? And these are questions as to what we need to do. So if you have two banks, a SHA-1 and a SHA-256, do we, somebody could start adding the IMA measurements in the wrong bank and pretend that it's the right measurements. So we need some method of tainting it. The current thought at the moment is that instead of tainting it in the TCG terminology of tainting, we're going to either pad or truncate the hash and use that measurement into the other banks so that we can actually then use a single bank for doing the attestation. So we're getting closer to closing the measurement and appraisal gaps. We have to be aware that of not adding new things that will open more gaps. And it is possible for distros for people to start including their software signatures at a file level. We still have plenty to do. This is not a full list. Any questions? Yeah, you have to re-sign it. Because Debbie and I wasn't the one involved in the, I did the initial implementation where we included it in the MD5 sums file, but now it's part of the TAR itself. But in either case, you're opening and repackaging and having to reseal it. Yeah, to re-sign it. Thank you.