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
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.
The text was updated successfully, but these errors were encountered:
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.
Hello! Based on this discussion (paritytech/polkadot#7334 (comment)) it seems it may be possible for attackers to bypass sandboxing of spawned thread?
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.
The text was updated successfully, but these errors were encountered: