I am working on a project that involves the initial thread spawning new tasks and inserting specific capabilities in their CSpace upon request. For security, I want to understand all the ways a task can mess with its capabilities and CSpace. Specifically, I am curious if a task has access to its root cnode for minting or copying caps. I am using Rust seL4, and I have not found a way to perform these actions without being handed the cnode capability by the initial thread. However, I am still new to the API and want to make sure I am not forgetting anything. The child task can still access capabilities placed in the CSpace, so I think I am missing some alternative way to access/edit the root CNode inside the child Task.
To summarize, what is a spawned task allowed to do with its CSpace if it is not explicitly provided the capability to it?
To summarize, what is a spawned task allowed to do with its CSpace if it is not explicitly provided the capability to it?
It’s only allowed to use it to resolve other capabilities reachable via the CNode bound to their TCB. It can’t use the CNode bound to the TCB for CSpace operations.
All CSpace modifying syscalls require a capability to a CNode that is fully resolved and not an intermediate CNode. The manual explains it as:
“CPtr to the CNode that forms the root of the destination CSpace. Must be at a depth equivalent to the wordsize.”
Practically this means it is safe to have a multi-level CSpace, as intermediate CNodes can be used to resolve capabilities, but can’t be used themselves for CSpace modifications.
That is why the initial task gets a cap to its own CSpace during bootup, in addition to having it bound to its TCB.