Restrict process instead of thread

[l0kod]

Currently, landlock_restrict_self(2) applies a ruleset on the calling thread, which makes sense from a kernel point of view, and enables some use cases such as tests. However it might be misleading for users, and it requires additional work to make sure all threads are properly sandboxed.

It would be useful to be able to safely and atomically restrict the entire calling process. The main constraint would be for all sibling threads to have the same credentials. This should work the same way as seccomp(2)'s SECCOMP_FILTER_FLAG_TSYNC, and the interface would be an additional LANDLOCK_RESTRICT_SELF_PROCESS flag for landlock_restrict_self(2).

[l0kod]

Related issues for the Rust library:

• Possibility of bypassing sandboxing of threads rust-landlock#37

Related issues for the Go library:

• RestrictPaths needs to apply to all OS threads and Goroutines at once go-landlock#5
• landlock/syscall: use syscall.AllThreadsSyscall{,6} directly go-landlock#17

Thread handling with the Go library:

• landlock-lsm/go-landlock@9c85320

[praveen-pk]

The main constraint would be for all sibling threads to have the same credentials.

@l0kod what credentials are you referring to here?

With this enhancement are users expected to invoke landlock_restrict_self once per process, in a thread which is aware of all the resources all the threads in the process will need?

[l0kod]

The main constraint would be for all sibling threads to have the same credentials.

@l0kod what credentials are you referring to here?

It's the Linux's struct cred which contains all security information (e.g. UID, capabilities, Landlock domain...)

With this enhancement are users expected to invoke landlock_restrict_self once per process, in a thread which is aware of all the resources all the threads in the process will need?

Yes. Of course this will be an option. This will work the same way as SECCOMP_FILTER_FLAG_TSYNC.

[l0kod]

Cc @allenpais

[allenpais]

@l0kod Could you assign this issue to me. Thanks.

[gnoack]

@allenpais FYI, starting with the "scoped" IPC operations in Linux 6.12,
the identity of Landlock domains starts becoming relevant for enforcement,
and it would now be really useful to have support for whole-process Landlock enforcement.

Are you still actively working on this?

See
landlock-lsm/go-landlock#33 for more details.