Restrict whole process

[l0kod]

The kernel will eventually enable to handle all the threads from the current process (see landlock-lsm/linux#2), but it would be good to do the same from the currently available user space features.

See the Go library: landlock-lsm/go-landlock@9c85320

[hammerandtongs]

So can you clarify what the effective use of path_beneath_rules() actually is if called from that start of your main, particularly within an async runtime?

My expectation from my lazy "get it done" integration was that this would give me a process that was restricted but that sounds like its not yet there and I might need to repeatedly call my restrict function anywhere I think there is a thread created?

[l0kod]

So can you clarify what the effective use of path_beneath_rules() actually is if called from that start of your main, particularly within an async runtime?

Because main() is the first thread, restricting this thread will automatically propagate the same restrictions to new/future threads from the same process, so there is nothing specific to but sandbox early.

async functions should not be an issue because they don't require dedicated threads. However, some runtimes may spawn a pool of threads to dispatch workload.

My expectation from my lazy "get it done" integration was that this would give me a process that was restricted but that sounds like its not yet there and I might need to repeatedly call my restrict function anywhere I think there is a thread created?

You just need to restrict the first thread before any new ones are spawned. Keep in mind that there are no security boundaries between Linux threads, so all threads must be sandboxed the same way. If the code repeatedly restricts itself, then something is wrong about the sandboxing implementation.

[n0toose]

Before I stumbled upon this issue, I had some difficulties with understanding this problem (see: landlock-lsm/linux#2) when testing different cases using cargo test integration tests (which spawns new threads for each test - so, "it all unexpectedly worked for some reason").

It would be great if the possibility to restrict the whole process were "opt-in", in a sense.

P.S. A weird "edge case" that I noticed was that, when restricting a thread / test, such tests have to be run serially (and not in parallel), otherwise the restrictions of one test-thread might "leak" to the restrictions of another test-thread. Not sure if this is expected behavior warranting a new issue. (Possibly related to: #57)

[l0kod]

Before I stumbled upon this issue, I had some difficulties with understanding this problem (see: landlock-lsm/linux#2) when testing different cases using cargo test integration tests (which spawns new threads for each test - so, "it all unexpectedly worked for some reason").

What do you mean by "it all unexpectedly worked for some reason"? Rust tests usually run in dedicated threads and Landlock is enforced per thread, so there is no issue with cargo test. See our CI: https://github.com/landlock-lsm/rust-landlock/actions

It would be great if the possibility to restrict the whole process were "opt-in", in a sense.

Yes, it will be opt-in, like all new Landlock features. Otherwise it would be a Linux kernel breaking change.

P.S. A weird "edge case" that I noticed was that, when restricting a thread / test, such tests have to be run serially (and not in parallel), otherwise the restrictions of one test-thread might "leak" to the restrictions of another test-thread. Not sure if this is expected behavior warranting a new issue. (Possibly related to: #57)

Landlock restrictions don't "leak" to sibling threads, they are only inherited to children threads/processes (otherwise it would be trivial to escape). There is probably an issue with your tests (e.g. that recycle a previously restricted thread).

[l0kod]

Before I stumbled upon this issue, I had some difficulties with understanding this problem (see: landlock-lsm/linux#2) when testing different cases using cargo test integration tests (which spawns new threads for each test - so, "it all unexpectedly worked for some reason").

What do you mean by "it all unexpectedly worked for some reason"? Rust tests usually run in dedicated threads and Landlock is enforced per thread, so there is no issue with cargo test. See our CI: https://github.com/landlock-lsm/rust-landlock/actions

Well, that may not be enough: if you test restrict_self(), each test should spawn an ephemeral child thread, see #46.

It would help to have access to the tests.