 All right. Any other questions on this from me? Or should we give someone else a chance to talk about signing stuff up here? So this is very early warning, right? This is heavy prototype stuff. The goal that we're trying to solve is establish a BPF security domain. And we want to say that only executables within that domain, right? These are like the executables I trust to run the BPF syscalls should be allowed to load BPF programs. Now, in a simpler concept way, this is a Mac policy using BPF LSM. And the use case I'm choosing for this is that just allow only BPF trace load BPF programs. The implementation of the Mac policy is fairly simple. You set up extended attribute on BPF trace saying, security domain BPF, which tells the whole LSM framework that, OK, I trust this to load the BPF execute BPF syscalls. We need a new helper for this. This helper is called BPF getXutter. We need it in the BPF program to get the value of this domain. And then we use light skeletons. And we implement some LSM hooks with the light skeleton there. So we have the first hook that is BPRM committed creds. For it's just fancy name for a process is executed, right? In this hook, we get the exciter from the executable, right? And store this information about the exciter in the task blob. And task blob, again, is like for BPF folks, task local storage. The next LSM hook we implement is task alloc, which is when this task forks, you want this capability to the, for example, if BPF trace decides that I'm going to run the BPF syscall in child process, then you want this child process to have capabilities as well. So you transfer these sort of security state into the child task. You may choose to do that. You may choose not to do that. That's the beauty of the LSM implemented in BPF. BPF progs syscalls. So you essentially do what we want to do. You deny BPF syscalls from non-BPF domain processes tasks. And then you also implement, deny any attempt to set new extended attributes. You could create a new domain, right? Like a trusted executable or something that is allowed to create or set exciter. But for simplicity, you can just disable it. And you can set this exciter in a trusted environment where you're creating this image. So I'm going to show you the demo now. And then we can discuss some of the deficiencies of L-scale that we should probably fix in this area. I hope my, yeah, so, oops. I'll just show you the code here quickly as well. The code is fairly simple. So this is, let me just zoom in a bit. So this is the task. I'll start with the BPRM committed credits hook. It is a sleepable hook because this get exciter function actually requires, it can sleep. That's not too bad. So you get the extended attribute. This security exciter name is just security.domain here. You do a task storage get, right? And then you, I mean like, oh, so yeah, this is wrong. We should edit it in the YouTube video. So then you compare whether the value is like, for like BPF exciter domain, you can set like a storage domain, exciter security, you can set like, there is, I mean, there is some improvements you can make here. You can create a bitmap and then the domain can be like a composition of these multiple domains. But I keep it simple and I just say you can just be in one domain. So you can either be an exciter, exciter, or you can either be like a BPF program executor, right? Then the BPF program LSM hook is fairly simple. It just reach the blob and then it can like, it denies the BPF's calls for stuff that is not in the domain. And the inode set exciter is very similar. It denies for like something that is not in the exciter domain. Task alloc is also the thing we talked about, right? The new task that is currently being formed and the current task that is forming the new task, there is a security transfer state that is happening here. So let's see if this really works. I keep a quick question. So the security dot prefix, how relevant is that? I tried setting something without arbitrary extended attributes, it wasn't allowing me to set that. I wouldn't, I don't care about the security dot prefix, but it's just that it wasn't working about without that prefix. There are certain, and this is, I claim like less knowledge here, right? Extended attributes can only be set of certain types and there is like a domain in the beginning and this is a security domain. We could use, we could create a new domain that is called BPF, right? But this will need some kernel changes. I didn't want to do any kernel changes for this yet. I used the security dot BPF domain and it just worked. Now security dot and you can have whatever after that. So let's go to the demo. So this is my VM. Let's search the exciter. Let's see what the exciter is. Then as I claim, there is a exciter that says here. Let's also check like the test progs program which doesn't have the exciter. Oops. Yeah, it doesn't have any exciter. So what we do is we say, control our BPF trace. So this test progs obviously doesn't work because we need trying to sort of allow test progs to run by setting this, it doesn't work. I can do BPF trace and this actually works. So it says this, right? I can try doing test progs again and it's denied. So simple policy using exciter stuff. I think there is a lot of like, if you talk to some security folks on my side or like even in the LSS, they're gonna poke a bunch of holes. Like you need to do extra LSM checks to this. But I think we can construct a fairly comprehensive policy using just exciter and BPF LSM hooks here. That's all. Brent, does that answer some of the questions around BPF trace like things? Could we use this to store the aforementioned signature required for the program? Not a bad idea. Oh, yeah, true. Yeah. If you look at like libbf tools for example, you can have like five different programs but like at any given kernel you will start like two or three of them. Because like other alternatives for like older kernels or like stuff like that. So BPF, it's like, I keep talking about BPF application. That's a collection of programs and maps obviously but it's never a single program. Like well, not never but like very often it's not a single program so. So I think there's one thing I missed sort of discussing about what we should discuss is the whole L's light skeleton stuff is pretty awesome. Like it allows you to create this kernel module that is loadable. But there are a few things that are missing here. The code needs to be checked in. So I did modify iterators.bpf.c to have this code written. So we probably need some sort of a delegation file in the kernel that we could point to other sources. And then just say like, look, this is where my light skeleton is file is located. This is the kernel module file and this is the stuff. It should generate the right bits in the kernel so that all the preload calls can be called from the kernel. And then like you don't have to, ideally one should not be required to check in the source code with the kernel here. So that's one improvement that I was sort of discussing yesterday and probably we should think of here for the light skeleton stuff. There were other couple of minor niggles which I like I can talk about. There was a small bug in the LSM skeleton for BPF tool where the FD that is allocated is it doesn't raw trace point open for like LSM programs. It does it for only trace tracing programs with small stuff. And then there is a bug here. Like because I preloaded the module, it doesn't really like populate in CISFS. So this is something we should fix as well. Yeah, so like even though the file should exist, I think if I do a remount of the CISFS, it should like BPFFS, it should show up. On some of my remounts, I got a null pointer exception here. So I would like, yeah, minus DBPF and I think BPF. Yeah, it doesn't show up even now for some reason. So there is some race going on where the dash A. No, I don't, it's not with a dot. The file, I named the file, it's actually not with a dot. The file, I create files. There are these pre-populated like in the code you can see in the, yeah. So what kind of mechanism do you think will be useful? Like passing something on the command line, boot command line to preload the set of programs or what do you have in mind? Probably like a manifest file of some sort, right? Like which contains pointers to like the sort of your, this preload kern type thing which provides the preload operations and then a set of BPF programs or like light skeletons, it loads. But like you still need to, do you want to recompile the kernel or not? So if I recompile the kernel, of course it can be in the source code, right? Like I'm happy to recompile the kernel. I just don't want to check it in the kernel source tree. I want to point it to like these locations. Like there is, these look like kernel patches to me and they are actually not, right? But you can compile a kernel module outside of the kernel tree, right? Easily. So same thing. I'm not sure, like the kernel modules can't be compiled anyway, right? They don't need to be part of the kernel to be. So just, this is your kernel module, just keep it somewhere else. This is when I'm building it with equal to M, right? I also want the capability to build it with like, as built into the kernel tree so that I can do an early boot. In this case, this whole framework sort of assumes that this is just located in the kernel tree itself. Well, for built in, yes. For built in for the module to become dash equal yn to be built in. And during the early boot before being in it before anything, well, it has to be compiled with the kernel as part of the kernel tree, yes. So you're saying change that so to have built in kernel modules that are outside of the, this is just like directory-wise located outside. So essentially K built extension. Exactly, like something that allows the engineers who want to use this functionality but they don't want to mess with the kernel source tree more than just the configuration option that allows them to specify where this stuff is located, right? It's mostly a development thing. It's not a functionality. I think the functionality thing was one, the missing thing in BPF tool, and the other one was. No. Is there a precedent in kernel where you embed something in the kernel that's not checked into the kernel repository? Because that's what you try to do. Device tree? What? Device tree stuff, like, I don't know. Like, I vaguely recollect some of these things but I don't know the precedent. I'll have to do some digging. Can you elaborate on the earlier comment? So you were saying that the X-Adder stuff may not be enough like to implement this safely or like? I think it is good enough, like for me, but I want to run this by a few like security folks and like try to poke holes in this, right? It's an LSM and it claims to give strong security properties, it shouldn't have any bugs in that. Yeah, okay. Please send the patch for gets a pattern. Yes. Since you have a trade, it's such a... Yeah, I have finally got... Polish it and send it. Yeah, I have the best part, this is good advice because if I don't send it for three more months, the tree will move forward and then I will spend three more hours fixing this. So yes, I will send this patch before I leave this place. And your sample code is a self-test? Of course, yes. Action item? Clear action items for me. I think we... I've finished. Awesome, thank you. Thank you.