-
Notifications
You must be signed in to change notification settings - Fork 13
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
Modeling potential attacks to our secure compartment switch model #58
Comments
I think what we should be focusing on is the information provided by the containers themselves to |
In #55 , we introduced what we believe is a secure model of performing compartment switching. At a high-level, the idea is to provide compartments a capability (sealed with
lpb
type, meaning to be used in load-pair-branch instructions) which points to the DDC/PCC to be used byswitch_compartment
. These capabilities are within the memory "owned" byswitch_compartment
, and not accessible to compartments, due to DDC bounds. Compartments can provide an id toswitch_compartment
to perform the transition to another compartment (data for which is similarly stored in memory covered byswitch_compartment
DDC).To emphasise this, and to future proof the model, we introduce a number of negative examples:
try_deref
, where a compartment attempts to dereference its provided capability, which would essentially provide it with the DDC used byswitch_compartment
. This fails, as the provided capability is sealed.update_ddc
emulates a program where the address of the DDC to be used byswitch_compartment
is leaked (this is similar to the above, except the provided capability would not be sealed). The compartment attempts to load the DDC, but fails, as it lies outside its own DDC bounds.redirect_clr
attempts to install aclr
which points to a malicious function onceswitch_compartment
exits. However, the only way for the compartment to derive a capability to install inclr
is to use its own PCC, meaning that the malicious function would lie outside executable bounds upon returning.The existing examples provide one method of implementing the above attempts at breaking CHERI security guarantees - there might be other ways of implementing the above ideas. The question for this issue is are there any other potential methods of attempting to subvert security guarantees in our model.
The text was updated successfully, but these errors were encountered: