Open l0kod opened 10 months ago
Related issues for the Rust library:
Related issues for the Go library:
Thread handling with the Go library:
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?
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
.
Cc @allenpais
@l0kod Could you assign this issue to me. Thanks.
@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 https://github.com/landlock-lsm/go-landlock/pull/33 for more details.
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)
'sSECCOMP_FILTER_FLAG_TSYNC
, and the interface would be an additionalLANDLOCK_RESTRICT_SELF_PROCESS
flag forlandlock_restrict_self(2)
.