As previously advised, I am using getauxptr(AT_CHERI_SEAL_CAP) to obtain a sealer capability. However I don't understand how this can provide any security, because all processes can obtain a root capability from which they can derive any valid object ID.
Given the object ID can be read from a sealed capability, this surely means any sealed capability can always be unsealed even without access to the original sealing capability? At least in the same process, this is possible.
My understanding of capability sealing is it prevents use of the memory referenced by the sealed capability by a 3rd party, so how does use of deriving a capability from the aux vector like this provide security?
I presume that (when this feature gets implemented) if the PE is in restricted state then it should not be possible to obtain the AT_CHERI_SEAL_CAP capability - so is this the only mechanism by which the security is provided?
Please correct me if I am wrong - and provide links to appropriate media (if applicable) to explain this further for the Morello implementation of CHERI, so that I can increase my understanding.
Additionally, AT_CHERI_EXEC_RW_CAP and AT_CHERI_EXEC_RX_CAP seem to be effectively unbound (as if they were the to-be-deprecated DDC) - should these not instead be bound to not more than the memory range of the loaded ELF image?
Hi Kevin, thanks for taking the time to write such a detailed reply and for the issue link - this is very helpful!