Comment by notatoad

LWN's article on unveil() is a good explanation - the restrictions are permanently applied to the process and its children until termination: https://lwn.net/Articles/767137/

The kernel enforces that once the policy gets added it can't be removed.

So the restrictions are permanent for the life of the program. Even root can't undo them.

Since it can’t re-enable privileges during runtime, the compromise would have to modify its own code and restart; if you don’t allow the running process to access its own code, it couldn’t make any changes that would persist across a restart of the code.

As the article states. You can not give extra permissions only limit further.

Reading this as a web developer, it reminds me of Demo's permission system.

Deno is a JS runtime that often runs, at my behest, code that I did not myself write and haven't vetted. At run time, I can invoke Deno with --allow-read=$PWD and know that Deno will prevent all that untrusted JS from reading any files outside the current directory.

If Deno itself is compromised then yeah, that won't work. But that's a smaller attack surface than all my NPM packages.

Just one example of how something like this helps in practise.

> if the application were compromised in some way, wouldn't it simply un-restrict itself?

The API doesn't allow un-restriction, only restriction. Since one typically applies restrictions at program start, they will be applied before an attacker gains remote-execution, and the attacker is then limited in what they can do...

The kernel guarantees that once restricted, that process will stay restricted. The only way for it to un-restrict itself would be to also compromise the Linux kernel. So you have 2 things you have to compromise to own the machine, instead of just 1.

For sandboxes where the underlying software is assumed to be non-hostile (e.g. browser sandboxes), these kind of restrictions can be applied very early in a program's execution. If the program doesn't accept any untrusted input until after the restrictions are applied, it can still provide a strong defense against escalation in the event of a vulnerability.

codex-cli is a neat example of an open source Rust program that uses Landlock to run commands that an LLM comes up with when writing code (see [1]). The model is that a user trusts the agent program (codex-cli), but has much more limited trust of the commands the remote LLM asks codex-cli to run.

[1] https://developers.openai.com/codex/security/

The point is it can’t.