Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict whole process #62

Open
l0kod opened this issue Feb 21, 2024 · 2 comments
Open

Restrict whole process #62

l0kod opened this issue Feb 21, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@l0kod
Copy link
Member

l0kod commented Feb 21, 2024

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

@l0kod l0kod added the enhancement New feature or request label Feb 21, 2024
@hammerandtongs
Copy link

hammerandtongs commented Apr 2, 2024

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
Copy link
Member Author

l0kod commented Apr 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants