 Yeah, I'm Caste, this is going to be hopefully a pretty quick update here. The agenda I'm covering, what James mentioned already. Just a quick background on sort of the distinction on the LSMs, and we'll get through it. Anyway, so sort of the regular LSMs are the ones that have comprehensive policy language and cover the sort of the full mandatory access control system. There's also integrity and capabilities, which are different, but use capabilities you can't opt out of, and integrity is sort of next to the LSM stack. The small LSMs tend to have a very narrow or fixed policy that do a specific task that is sort of out of scope for some of the other Macs. I maintain Loadpin and Yammer, and there's also the safe set ID that I've talked about earlier for narrowing the set user capability, and soon we'll have the lockdown LSM. So the Loadpin LSM was designed due to the fact that signing kernel modules doesn't make any sense if you already have total control over the device that those modules are going to come off of. The example being Chrome OS uses DM Verity that's got a cryptographically verified read-only root file system. So I don't need to sign those modules, they're effectively already signed, I just need to make sure they're only coming from that block device. And that was what Loadpin would do is it says wherever I get my first module from, that's the block device, that's the file system they have to come off of forever. And this was extended to K exec images, firmware, security policy, anything that the kernel reads as a file, Loadpin can cover and pin to locations. Thankfully, this is pretty stable, so it's easy to be a maintainer of it. So some minor changes in initialization output and what the boot parameter name was, turn it on. It was only about ptrace restrictions, it was the first stacked LSM, sorry, not sorry. And it tries to narrow the scope of ptracing events from what was effectively the same UID to saying an ancestor of a process tree or an explicitly whitelisted process. And the goal there was to increase the amount of time necessary for an attacker to start stealing credentials. Because if someone gets into your system and they have to wait around for you to type the now backdoor version of SSH you have installed, you have some time until you made the attack and the user logs in and falls into your trap. So instead of being able to attach to the existing SSH things or any other credential holding processes, you can't do that because you are not an ancestor of those. That was the design goal. This is also pretty stable in 5.0. Says Caller found a corner case in RCU races around task death that no one else had found yet. So again, pretty stable and lots of distros have it as part of their build. Libsecomp is not an LSM, but it's sort of a security subsystem, so I include it here. It's used all over the place and it's sort of next to no new privs, and there's some good ideas on ways to wrap your code easily if you don't want to write your own stuff. Libsecomp got talked about earlier in the conference, and if you want to do really crazy things like I'll show in a second you probably need to learn BPF a little bit, which is a subset of classic BPF in seccomp and not EBPF. To that end, seccomp basically looks at this data structure in the kernel. You can match against what syscall number it was, what architecture you're on in case you have a compact architecture which has a different syscall numbering convention, the instruction pointer that called you and the arguments, and you can't see anything more than that. You cannot follow the pointers that might be in an argument because that's racy because if seccomp checks it, then later the syscall might see something different. So there is not yet deep argument inspection on seccomp. When you write a filter, you can return these various results like allow the syscall and then a whole bunch of different variations all the way up to kill that particular thread or kill the entire process. So there's a greater, you know, peril for your process depending on the filter results. The new one that got added is in the middle there is the seccomp return user notification. This is when you attach the filter, you get a file descriptor back and you can actually interact with that file descriptor as it gives you, it'll stop, signal that file descriptor, wait for the response, skip this, skip over the syscall, and then return the results that were in that. Right now it skips the syscall always, but there was some discussion this week about, well, can't we just also have a way to say, okay, continue with the syscall, unmodified? I worry about this a little bit because I'm concerned users will start checking, like, start doing deep inspection and say, sure, that syscall looks good to me. It should continue. In fact, it's the reverse, which is I want to be able to handle something special that you don't have access to, like, outside of a container. And then we could possibly, with that, we could also change notifications. You could signal the FD and say, I don't want to hear from you again. Just carry on forever or come back from that. So now, anger everything with a demo. Luckily, there is already a sample of how to use user notification called user trap. I'm going to try to rename that file because that's not the greatest name for it. Let's see if the demo God's like me or not. Can't see me. Hold on. Okay, so this is sort of the setup of where you would do user notification. If you're familiar with any of the BPF, you can see the second return user notification. Later on, in whatever has been confined with this, you could say in the example that he has, he was using mount because that's the thing, but I'm just going to show an even more insane version of this. We're still going to call mount, which would normally fail, but this will be more fun. So we're going to call mount twice, and it reports the specific air know that we're getting out. And on the management side that's listening on this, it's just performing an eye of control to receive notifications and it handles it and sends it back. So make things really big so you can see it. So this is calling mount, and we've popped a giant notification. And let's pick an air know. I don't know what these are. It's 104. 104 is, hold on. Oh, connection reset by peer. Okay, I've actually heard of that, sure. How about in the 60s? Out of streams resources, sure. Anyway, that's it. That's the end of my presentation. Thank you.