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:

• landlock-lsm/rust-landlock#37

Related issues for the Go library:

• landlock-lsm/go-landlock#5
• landlock-lsm/go-landlock#17

Thread handling with the Go library:

• https://github.com/landlock-lsm/go-landlock/commit/9c8532087aaaee020926dace107a4b2f152f97ed

[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.