LWN: Comments on "Sandboxing with the Landlock security module" https://lwn.net/Articles/703876/ This is a special feed containing comments posted to the individual LWN article titled "Sandboxing with the Landlock security module". en-us Wed, 22 Oct 2025 01:54:04 +0000 Wed, 22 Oct 2025 01:54:04 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Sandboxing with the Landlock security module https://lwn.net/Articles/704929/ https://lwn.net/Articles/704929/ filssavi <div class="FormattedComment"> that effectively makes more sense now <br> </div> Fri, 28 Oct 2016 15:35:50 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704849/ https://lwn.net/Articles/704849/ Wol <div class="FormattedComment"> Because it can't?<br> <p> As I read it, you set up the environment, then run the program inside the environment.<br> <p> So no process can "reach out" to another process that's already running. You would need to intercept the login process and restrict that.<br> <p> Cheers,<br> Wol<br> </div> Thu, 27 Oct 2016 17:27:24 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704764/ https://lwn.net/Articles/704764/ filssavi <div class="FormattedComment"> So if an unprivileged user's process can (more or less arbitrarily) limit the capabilities of any other process from that user, what stops a compromised pice of code from trashing the system by overlimiting any existing process from the same user? <br> </div> Thu, 27 Oct 2016 07:42:40 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704644/ https://lwn.net/Articles/704644/ l0kod <div class="FormattedComment"> RFC v4: <a rel="nofollow" href="https://www.mail-archive.com/netdev@vger.kernel.org/msg134194.html">https://www.mail-archive.com/netdev@vger.kernel.org/msg13...</a><br> Associated repository: <a rel="nofollow" href="https://github.com/l0kod/linux/commits/landlock-v4">https://github.com/l0kod/linux/commits/landlock-v4</a><br> </div> Wed, 26 Oct 2016 14:12:02 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704082/ https://lwn.net/Articles/704082/ l0kod <div class="FormattedComment"> Firejail use Linux namespaces and seccomp-bpf. Landlock is a (low level) kernel feature similar to seccomp-bpf. Landlock should then be useful to sandbox managers like Firejail or any other software willing to do sandboxing (e.g. web browser).<br> </div> Thu, 20 Oct 2016 14:09:56 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704076/ https://lwn.net/Articles/704076/ corbet LSM hooks are purely restrictive - they can reduce access, but cannot increase it. So, unless there's a bug somewhere, an attacker cannot escape by attaching more programs. Thu, 20 Oct 2016 13:33:19 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704054/ https://lwn.net/Articles/704054/ gutschke <div class="FormattedComment"> If it's anything like how seccomp-BPF works, then programs are indeed stackable, but each additional program can only serve to narrow permissions. And no, once a BPF program has been attached, it cannot be removed.<br> </div> Thu, 20 Oct 2016 06:17:58 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704052/ https://lwn.net/Articles/704052/ fredrik <div class="FormattedComment"> How does this compare to firejail?<br> <p> <a href="https://firejail.wordpress.com/">https://firejail.wordpress.com/</a><br> </div> Thu, 20 Oct 2016 06:05:44 +0000 Sandboxing with the Landlock security module https://lwn.net/Articles/704034/ https://lwn.net/Articles/704034/ JdGordy <div class="FormattedComment"> Maybe I'm misunderstanding, if the BPF program doesn't need root to be attached, what's to stop an attacker just attaching a new BPF to get out of the sandbox once the sandboxed program is exploited?<br> </div> Thu, 20 Oct 2016 03:15:24 +0000