"Landlock" Lands In Linux 5.13 For Unprivileged Application Sandboxing

[phoronix]

Phoronix: "Landlock" Lands In Linux 5.13 For Unprivileged Application Sandboxing

Going back about a half-decade has been the Landlock Linux Security Module (LSM) as a means of allowing even unprivileged processes to create "powerful security" sandboxes. After a number of rounds of reviews and revisions over the year, Landlock has finally been mainlined for Linux 5.13!..

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Landlock-Lands

[elatllat]

I think some sandbox examples are in order, VMs, containers, cgroups, unshare, landlock... or maybe just use independant hardware because we can't trust the speculating hardware or memory unsafe kernel.

[Volta]

I think some sandbox examples are in order, VMs, containers, cgroups, unshare, landlock... or maybe just use independant hardware because we can't trust the speculating hardware or memory unsafe kernel.

This 'memory safe kernel' or independent hardware will protect you against third party applications without sanboxing them? I got it, using Rust makes people harmless. Make Rust not war.

[uid313]

This 'memory safe kernel' or independent hardware will protect you against third party applications without sanboxing them? I got it, using Rust makes people harmless. Make Rust not war.

Google is using Rust for Android and Microsoft is using Rust for the Windows kernel. Microsoft research discovered that 70% of all security vulnerabilities were memory-related, which is why they investing in Rust.

Of course there can still be logic bugs that result in vulnerabilities, and security is complex so you need a multi-layered approach to security.

[ssokolow]

Google is using Rust for Android and Microsoft is using Rust for the Windows kernel. Microsoft research discovered that 70% of all security vulnerabilities were memory-related, which is why they investing in Rust.

Of course there can still be logic bugs that result in vulnerabilities, and security is complex so you need a multi-layered approach to security.

Exactly. Defense in depth.

Just because I write something in Rust doesn't mean I don't also at least run it under something like Flatpak or Firejail or systemd's built-in Firejail equivalent (the RootDirectory, NoNewPrivileges, ProtectSystem, PrivateNetwork, etc. directives. See systemd.exec(5)) or build it for WASI and run it via wax.

(wax is the npx equivalent for the Wasmer WebAssembly runtime and, on its default settings, it constrains anything you run under it to $PWD.)

Ideally, the only applications which shouldn't be running under one of those technologies are things like Zsh which need broad enough permissions that you have to use something like SELinux if you want to constrain them.

[debrouxl]

What about S.A.R.A., another piece for defense in depth, inspired by PaX MPROTECT implemented a very long time ago ? The development tree still seems "active" (latest commits in March 2021), but it's been a while since I saw a mention of mainlining it. Maybe its developer doesn't have enough time to deal with bikeshedding.

[MadWatch]

I don't mean to troll or anything, I just don't understand. How many sandboxing solution do we need actually?

We already have AppArmor and SELinux. From what I understand (please correct if I'm wrong) Flatpak and Systemd sandbox stuff using only native Linux features (I mean non LSM stuff) like like seccomp and cgroups. What is Landlock bringing to the table that isn't there already?

[Volta]

Google is using Rust for Android and Microsoft is using Rust for the Windows kernel. Microsoft research discovered that 70% of all security vulnerabilities were memory-related, which is why they investing in Rust.

The point was Rust itself won't save us from intentionally harmful third party applications.

Of course there can still be logic bugs that result in vulnerabilities, and security is complex so you need a multi-layered approach to security.

Exactly!

[mb_q]

I don't mean to troll or anything, I just don't understand. How many sandboxing solution do we need actually?

We already have AppArmor and SELinux. From what I understand (please correct if I'm wrong) Flatpak and Systemd sandbox stuff using only native Linux features (I mean non LSM stuff) like like seccomp and cgroups. What is Landlock bringing to the table that isn't there already?

They say it is about granularity; in a great simplification, seccomp & friends can be used to disallow you to open files in some paths, while Landlock disallows you to open files which were not created by certain process in the last 10 minutes or something crazy like this. It is accomplished by injecting policies in a form of eBPF programs into the kernel, which, at more-less every syscall, can investigate if the call is valid and disallow it if not.
The problem here is efficiency, obviously, and the fact that it allows unprivileged users to inject tons of new eBPF bytecode into many execution paths in the kernel, so it stretches the security of this technology.

[ssokolow]

The point was Rust itself won't save us from intentionally harmful third party applications.

...or compromised dependencies. I'm looking forward to seeing that whole WebAssembly nanoprocesses idea develop so whatever dependency manager I use (eg. Cargo for Rust) can gain support for presenting enforceable Flatpak/Firefox/Chrome/Android-esque "Grant these permissions?" prompts when I ask to add or update a dependency.