 Welcome to my talk on Landlock. My name is Michael. I work for KeenFolk. You probably have heard about KeenFolk by now. So this talk is about Landlock and Linux security module by Mikael Salyn. I hope I pronounced it right. And it's currently a proposal in version 7, so it's not yet merged upstream. The first IRC was published in March 2016. And it aims to be a Linux security module targeted at application developers. So in contrast to, for example, AppArmor or AssetLinux, the goal is to enable user processes, for example, your web application, to be able to restrict themselves by applying Landlock rules. This is not possible with the current version. The reason for that is that the scope right now is really minimal and the discussion focuses on the design. But once that is done, it will be changed. And in the end, everybody should be possible to restrict processes to the minimum required. Landlock is stackable. So I think stackable in two ways. The first way is that you can combine it with other Linux security modules. So it doesn't mean the administrator of a system doesn't have to care about security anymore. But it aims to make it possible that both the system administrator and the application developer can think about how this application should be secured, what should be possible, what not. And the second thing is that you can not only apply one Landlock rule, but you can apply many rules. So it's similar to a pledge from OpenBSD if you have heard about that. So there will be different families of rules covering different aspects of an application. And you can then combine this. What is unique about it is that it's using BPF. I won't touch any BPF specifics in this talk, but my next talk in the other room is actually about BPF. So if you want to learn about that, you can come. And the patch set right now is only focused on file system access controls, so it doesn't do anything else. And even that is a bit primitive right now because BPF is not yet powerful enough to really allow you to make or build rules that would enable you to do stuff like path checking. Path checking is just not possible in BPF to do reliable. So that's also work in progress. Why BPF or just BPF? It has a very limited kernel attack surface and a very strict verifier. It's used in a lot of places in the kernel nowadays. It has a lot of momentum. And since the future users of Landlock should not only be unprivileged but also untrusted, it's important that something is chosen which is properly verified by the kernel before it's applied. And BPF is perfect for that. So as long as there's no bug in the kernel verifier, you can be pretty sure that the rule will not interfere with the stability of your system. That's because the verifier, for example, makes sure that a program never has more than 4K instructions. Another thing is that you can't loop in your program, so you won't be able to denial of service the host system. Yeah, so that's what makes it a good candidate. I will show you how Landlock works right now. For that, I will use a demo application which can be found in the patch set in Linux. So I have a self-built kernel here with the Landlock patches applied. And we can also verify that Landlock is active. It is. And here we have a file, hello. And I can also touch this file, so this works. And I will now show you the same thing from a Landlock chain, so to say. One more thing. For that, I will load a Landlock rule. And this rule is an L file, so it's a BPF program compiled into an L object. And this program is the rule, and Landlock will load this rule to then contain the batch process that I'm about to start. So in K&Z, a new sandbox process was started, and I'm inside this new batch now. And when I repeat the same operation, I'm not allowed to do this anymore. And this is because this Landlock program does only allow read operations, not write operations. So I can still access the file, but not write to it anymore. And once I exit the process again, it works again. So I did this by using the Landlock subtype event file system. This is the only event which is available right now. We have learned before only the file system related events are considered for the first version, and other events can be added later then. And Landlock tries to target kernel objects with events, so it's not, for example, loading rules by syscalls, like SecComp does it. But it wants to separate those events by kernel objects. So in this case, the object is a struct file, and this object is used in many syscalls, for example, read and write. And for all those 33 hooks which group this file system-related actions, Landlock has loaded the rule. Landlock also knows about actions, so actions divide those events into sub-events or subtasks, so those enable you to decide what the event actually is about. So in the example that we just saw, writes were not allowed anymore, but reads still were allowed. And by checking the action in the rule, Landlock was able to decide if the request should be allowed or not. Sometimes there is no action parameter to an event, but something else, like an IOC control request, so that then depends on the event. And yeah, you have to look up the documentation to decide what you can do. So when the kernel starts, security modules gets loaded. So Landlock sets up its hooks there, and that happens at the start. We just started when I showed you the loaded Linux security modules. And then when a user application wants to use Landlock, it has to do two things. The first thing is using the BPF syscall to load the actual rule. And the second thing, using the second syscall to apply the rule to the process. The idea behind that was that in some scenarios, maybe the application that loads the rule is not the user application. So the first application could load the rule with BPF and then maybe pass the program file descriptor over a socket to the user application, which then applies the rule with secump. Once the program is loaded and applied, it gets triggered for all events which match the program subtype. We will see an example just in a moment. And this program then can do checks and signal the security module by return code if the action should be allowed or not. So either allow it, return code 0, or deny it, return code not 0. So the usual workflow to apply a rule is first restrict the own process to not gain any new privileges. And then by passing the proc file descriptor, which gets returned from the BPF syscall to secump. And after that, the process as well as the child processes will be restricted. To write a rule, we need two things. First the subtype, second the handler program. And this is the BPF specific part now. So in C, it looks like this. By convention, there should be a section subtype. So sec here is just defined to make sure that this struct ends up in the elf section subtype so that it can be found by the loader. And it defines two or three things. First the ABI, so which version of Landlock is required. Right now there is only version one. Then the subtype, this program is for. So we just use subtype event file system. And optionally, the ability this program should have that makes a difference in the BPF helper programs that are available for this handler. So for example, if you don't give this ability, the program won't be able to write messages into the trace pipe of the kernel. And this is how a handler program looks like so that's not the program we have seen in the demo before. It's just a short example. So you get a Landlock context which has a couple of fields. One of the fields is the event type. You need it to distinguish the events. And as said before, in the end, you can decide if you want to allow or deny. So this one would just print something to the trace pipe and then allow what you want to do. And it would also just print this message because this path of the if-else check actually can't be reached because there are no other types than subtype event file system. So if you are interested in the ongoing development of Landlock, you can check on the Linux kernel mailing list. The patch set is based on netnext because all the BPF development is happening in netnext. And since it also introduces a new BPF type, it had to choose the netnext tree and not, for example, master. And there is an org on GitHub. So you can find a Linux tree there with branches for each version of Landlock. So that's nice when you are interested in the history or want to have a look on older versions of the patch set. On the roadmap is C group handling. So the goal is to not only be able to apply rules to processes with a second, like we have seen, but also to C groups. And another one is a map type for file system related checks. So that's also the big blocker, so to say, why this can't fully work today because the BPF system itself does not bring the right tools to check for, for example, for a path of a file or stuff like that. Because you never get the full picture. You don't know in which mount neighbor space you are working. So you can never be sure which file actually is used. And also, as I said before, the unprivileged mode also is yet to be done. Yeah, that's it. Thank you. If you have any questions, I will try to answer those. So the talk. My question is, which part of that needs Capsus Admin right now? I thought both SecComp and that PR control, they could both be done as a normal user without capabilities. The BPF system needs it. And I'm not actually sure if they also have a check in SecComp. I think they do. So as I've seen, it's a special landlock rule call. And I think the decision was to also require privileges for that until the ABI is stabilized. But I'm not 100% sure if I recall correctly. OK, just didn't want to own everything. So how do you envision integrating this into actual applications? So do you put this landslide loader as a wrapper in system D units? Or do you start your program through that? Or how does it actually get applied to executables in the end? Well, I think both is possible. So I think there's the pledge use case. So you, as an application developer, can say, for example, OK, I only need to read and write from a var run foo. So I limit myself to this. But of course, it also would be possible that system D gains support for it. And you can set some flag or options in the unit file to restrict the process which is managed by system D. So I think both will be possible. So similar to the upperable profiles equals, that you can set that to the compiled rules file. Yeah, that could be OK. Are you looking at providing tools for programmers or for system administrators to actually watch programs that are running to get something like a profile for a program that is known good so that they can apply this set of capabilities to the application and then detect when it's deviating from that known good state? I think eventually that's something which would be nice to have. But I guess it's way too early right now to start working on that. So since the patch set is not in Linux yet, I think that's something for the far future. Next step maybe is to have libraries in Rust or Go, for example, to make this to just improve usability for application developers and then maybe tooling will follow more questions. OK, thank you.