lix-project/lix

Fork 59

Eventually implement landlock LSM for restricting abstract unix sockets #877

New issue

Open

opened 2025-06-25 14:28:22 +00:00 by jade · 8 comments

jade commented

2025-06-25 14:28:22 +00:00

Owner

Someone, I think @vriska, pointed out on matrix that it’s possible to landlock unix sockets into just their own landlock zone thing. This sounds sick, we should do it.

Problem is that they’re restricted to 6.12 and higher, or whatever libc bump we need for the headers. We could feature detect but it’ll be a pain until we have headers for it in stable nixpkgs, which maybe we do already?

Someone, I think @vriska, pointed out on matrix that it’s possible to landlock unix sockets into just their own landlock zone thing. This sounds sick, we should do it. Problem is that they’re restricted to 6.12 and higher, or whatever libc bump we need for the headers. We could feature detect but it’ll be a pain until we have headers for it in stable nixpkgs, which maybe we do already?

jade added the

stability

label

2025-06-25 14:28:22 +00:00

raito commented

2025-06-25 14:42:01 +00:00

Owner

25.05 has 6.12 but I'm not a big fan of it because VM tests that makes intense use of 9pfs cannot use 6.12 due to 9pfs folio management being broken there, FWIW.

vriska commented

2025-06-25 19:23:08 +00:00

Member

We could feature detect but it’ll be a pain until we have headers for it in stable nixpkgs, which maybe we do already?

Nixpkgs 25.05's linuxHeaders is from 6.12, so I think doing feature detection is probably fine?

> We could feature detect but it’ll be a pain until we have headers for it in stable nixpkgs, which maybe we do already? Nixpkgs 25.05's `linuxHeaders` is from 6.12, so I think doing feature detection is probably fine?

commentatorforall added the

Status

blocked

label

2026-01-04 11:59:08 +00:00

commentatorforall commented

2026-01-04 11:59:44 +00:00

Member

all kernel versions < 6.12 but 6.1 are marked for EOL in dec 2026, so maybe we can start working on this then

raito commented

2026-01-04 12:11:52 +00:00

Owner

It's better done at the systemd level in https://github.com/systemd/systemd/issues/37963

vriska commented

2026-01-04 15:58:33 +00:00

Member

(Also, as far as I know this isn't blocked? It'd just need a check that the Landlock ABI version is at least 6.)

@raito Doing this at the systemd level would presumably mean blocking abstract Unix sockets entirely, which I don't think is ideal if it's avoidable. Having the sandbox use Landlock would allow isolating each build such that they can use sockets independently. (Also, as far as I know this isn't blocked? It'd just need a check that the Landlock ABI version is at least 6.)

raito commented

2026-01-04 16:32:51 +00:00

Owner

@vriska blocking abstract Unix sockets at the systemd unit level would block them for nix-daemon@.service template and its subdaemons, do you have usecases of abstract unix domain sockets inside subdaemons but not inside builds themselves?

vriska commented

2026-01-04 22:24:05 +00:00

Member

What do you mean? The mechanism I'm proposing would allow builds to each use independent abstract Unix sockets. Am I misunderstanding the goal of this issue?

raito commented

2026-01-06 09:53:19 +00:00

Owner

@vriska wrote in #877 (comment):

What do you mean? The mechanism I'm proposing would allow builds to each use independent abstract Unix sockets. Am I misunderstanding the goal of this issue?

For me, the goal is first and foremost to harden against malicious derivations exploiting abstract UDS to cooperate with the external world or fellow derivations.

Enabling derivations to use abstract UDS for their testing and stuff comes second to me. In general, our own sandboxing code is not great so I would prefer not tack on more functionality in there until we overhaul it.

@vriska wrote in https://git.lix.systems/lix-project/lix/issues/877#issuecomment-17079: > What do you mean? The mechanism I'm proposing would allow builds to each use independent abstract Unix sockets. Am I misunderstanding the goal of this issue? For me, the goal is first and foremost to harden against malicious derivations exploiting abstract UDS to cooperate with the external world or fellow derivations. Enabling derivations to use abstract UDS for their testing and stuff comes second to me. In general, our own sandboxing code is not great so I would prefer not tack on more functionality in there until we overhaul it.