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

Possibility of bypassing sandboxing of threads #37

Closed
mrcnski opened this issue Jul 7, 2023 · 1 comment
Closed

Possibility of bypassing sandboxing of threads #37

mrcnski opened this issue Jul 7, 2023 · 1 comment
Labels
question Further information is requested

Comments

@mrcnski
Copy link

mrcnski commented Jul 7, 2023

Hello! Based on this discussion (paritytech/polkadot#7334 (comment)) it seems it may be possible for attackers to bypass sandboxing of spawned thread?

Since this only restricts a single thread any threads (including the main thread) which were spawned before this one will still be fully unrestricted, and since all of the threads share an address space if the attacker can execute arbitrary code they could just hijack another unsandboxed thread to do what they want. Slightly annoying but won't stop a motivated attacker.

Can you confirm that this is or isn't an issue with landlock? I haven't seen this in my research of landlock, or related techniques like seccomp, which allow sandboxing of single threads. If this is a real issue then a caveat should be included in the documentation so more people are aware of this and can take appropriate measures.

@l0kod
Copy link
Member

l0kod commented Jul 8, 2023

This is correct and explained in the documentation: Linux doc and man page. However, I agree that we should highlight this point.

A agree with @koute. A Linux thread is (mostly) a unit of scheduling, but should not be considered a security boundary, unlike processes. Linux's credentials are managed per thread, which might be confusing, but it is more flexible (e.g. for testing, improved safety guarantees). However, with some effort and a supported CPU (i.e. memory protection keys), it should be possible to efficiently restrict a thread, but this is not portable and should be considered a defense in depth mechanism.

Anyway, if a thread is considered potentially malicious, the whole process should be considered potentially malicious, and then the restrictions (e.g., Linux capabilities, DAC/UID/GID, seccomp, Landlock) should be enforced on this process.

With seccomp, you can synchronize all threads with SECCOMP_FILTER_FLAG_TSYNC but this can failed in some situations, which might be an issue and should then only be used for specific use cases. We plan to add such feature to Landlock but there is nothing like that for now.

@l0kod l0kod closed this as completed Jul 8, 2023
@l0kod l0kod added the question Further information is requested label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants