 So, secured module stacking is something I've been working on for a few weeks. It's actually been quite interesting, quite challenging, and I've learned a whole lot about implementations of Linux security modules. If you were here this morning, you heard some of that acquired knowledge. So what are we doing? Well, as of, I've got to turn the thing on again. I'll just forget to do that. Okay, so there we go. So as of Linux 5.1, we got the first set of the current development effort actually into the kernel. We have infrastructure-managed blobs for a small set, well, actually most of the security blobs. That means that they can be shared by more than one LSM. So as a result of this, the Tamayo security module is no longer considered a major security module. It can run in cooperation with anybody else, and it does. And this also gives us the sharing that we need in order to support the incoming Landlock and CERA security modules, which are in development. We've also gotten a good amount of feedback to the effect of other modules that people are wanting to do that they've felt that they weren't able to do because, well, I can't put it in because I have to run Fedora. And Fedora has to have SC Linux, and I can't take out SC Linux. But if I can have this other module in addition to SC Linux, I can work on that and be happy, and my IT department isn't going to run me out of the building. So we're actually getting a lot of good interest, a lot of good things coming into the pipe. As of 5.4, the next set of patches that are in development, and there's got a nice little asterisk there because there's still a couple of recalcitrant individuals who need to be convinced that this is the right approach that we've addressed, actually all the issues. We should be able to have, well, we will be able to have AppArmor and SC Linux or AppArmor and SMAC running at the same time. And John talked a little bit about this earlier. We actually are seeing a large number of use cases where people want to do sophisticated container environments where they want to run an Ubuntu-based system and they want to run Android containers on it. In order to do that, you need to be able to support both security policies. That doesn't get you everything that you want. It doesn't get you the ability to have different policies in your different containers, but it is the fact the next step in that direction. So we still have, in order to do that, there are a few things we need to do. We need to make the keysock and superblock security blobs infrastructure managed. That's easy. That's just a few lines of code. Since we've done it for the other blobs, we know what we have to do. We can actually do a couple of things when we do that to actually improve performance of all the LSMs that use those blobs. The way we've actually improved the use of the Inode blobs. And that's all the blobs that we have that we haven't actually converted that are used in more than one module. It's possible that somebody could implement a security module that uses other blobs that we haven't, that we won't have infrastructure managed, but there's nobody using those yet. And so we're taking the approach of, if it isn't a problem, we're not going to fix it. Now, one of the things that comes up when you decide you're going to have multiple security modules. What do you do about the context? Now, the security context is the text string that represents a security label or a security information and security blob. So we're adding a couple of interfaces to address that issue. We tried a whole bunch of ways of playing around with attributes and backward compatibility things that just didn't work and just didn't make people happy. So finally, I actually talked to somebody who does application development, one of the debuts maintainers. And he said, well, yeah, all these things kind of make sense, but the way I want it is, and as soon as he said that, he had me. He could have said just about anything at that point, and I would have said, fine, that's the way I'm going to do it. So what he said is, I don't want to have to look in proc adder current and switch around things or parse what comes out of there and guess which LSM it is. I want a separate interface that will tell me what the LSM is and what the data is. And I want it to be different because I don't want it to get confused when I write the debuts code, which one I'm talking about. So I'm going to be adding proc adder context, which is like proc adder current is today, except that it has data in the format of the LSM name, its value, LSM name, ANUL, its value, ANUL, the next LSM's value, name, ANUL, et cetera. And that way, it can parse it very easily. The interface, it will be null terminated. You'll get a certain number of bytes. It's easy to read out of proc adder context. We also want to add SO peer context to go along with SO peer sec. SO peer sec gets you the security context for one socket connection. This will get you the same thing for all socket connections rather than expecting people who are writing new code or code that's going to be cognizant of this to do anything fancy. Now, we also have a case. Oh, there's a bug on this slide. Pay no attention to that. This shouldn't say proc self adder context. That should say display. There are cases where you have legacy applications that know what LSM they want to work with that may not be getting that out of current. Now, for example, if you want to run the smack test sweep, it knows that what comes out of current is the smack value. Well, if you're running it on a system that has SC Linux and smack or app armor and smack and app armor is first in the list. The smack test suite just gets all confused. It's actually kind of amusing to watch. So we do have to have a mechanism where we can say environmentally, I'm going to run this program and when I run this program, it should get the smack values, not the app armor values. So there's mechanism proc self adder display, which if you have cap mac admin, you can set that and then run the programs that expect things to be the old and old way and it will work. This is for legacy, legacy support only. We really want people to move eventually to either a system where they're not having multiple modules or if they are, they're going to use the new interfaces because the new interfaces give them the information. And the new interfaces will work even if you only have one module installed. Audit data. You need to have more information in the audit record. If you've got three LSMs, any one of which could have denied you access, you really want to have it in the audit record, what the contexts were for all the LSMs that are involved. So of course we have to honor backward compatibility. So in addition to the existing object fields and sub fields, we're adding these additional fields which are object and then the security module and the value sub underscore and then the security module name and then its value. So that if you've got old tools, they'll still find subject and object. If you've got new tools, you can find it the new way. And if you have old tools but you want information that isn't in the old just subs field, you can take the audit record, run it through said and filter it so that you get the right information in the right place. So all the all the cases except the one where you're worried about amount of disk space. You are covered and yeah you're going to get more information in your audit trail because you have more information that matters. So and five point X. I'm hoping it's five. I just realized that I'm kind of making a supposition there. Five point X with complete stacking. We will have all the modules working together like horses in the Troika. So what's going to require going to be required there. There are some really interesting issues with NFS labeled NFS has an interesting property in that it, although there's a field for telling you what the format of the data you're sending is, it's not used. So the Linux implementation just assumes that since there's only one LSM that could possibly be reading this information. And you've got a rational administrator who wouldn't put a server that would serve anything else out on the system out there on the network that it's all going to be fine. They're all good. They're just going to agree so we don't have to worry about it. That's not a good idea. We've had some meetings actually over the past couple of days with the NFS developers about how we're going to go about addressing this. Hopefully we're going to get real extended attribute support out of it. But we'll see how that goes. Net label. Net label has got a really interesting aspect to the way it was implemented. Whereas most security security hooks are in the main processing line. Net label requires that the LSM call in advance and say here when you go do something out here on this side, here's what I want the values to be. So when it's actually doing the processing, it's just assuming that the data is already there and it's going to go use it. What that means is it's a little bit difficult for two LSMs that might want to put labeled packets out on the network to coordinate as to whether they're going to agree or not. So the solution to this, of course, is for the LSMs, for the Net label system to call back to the LSMs and say, hey, do you guys agree? And if they agree on what the labeling should be on the packet, then you can send it. If they don't agree, then it's got to get stopped because as a system here, we're not working out. And it turns out that SC Linux and SMAC have actually got quite different ideas as to how this should be used. So there are actually very few cases where you're actually going to get a packet out. But there are configuration things you can do that will actually make it work. But that's kind of the compromise you had to come up with in terms of you got two LSMs which want to use this. How are we going to make it so that it's safe? Okay, so there's the tree. There are several branches. And if the disk relabeling has finished, I'll have a demo. Let's see. Oh, yes, it has. Okay. So we are going to do this the hard way. There we go. Now, why isn't... Okay, that's not going to work. I'm not going to try to force it. Okay, it's not going to work. I'm just not going to force it. And all the demo was to cat syskern security LSM. And you'd see a big long list of LSM names, including App Armor, SC Linux, and SMAC. And a couple of others, one of which you've never heard of. Okay, so that's it for the stacking update. Thank you for now.