You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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.
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
The text was updated successfully, but these errors were encountered: