Construction and projection capabilities are not checked #14
Labels
error
Something is confusing, misbehaving, or harmful.
s:2 critical
This has the potential of causing a lot of harm; timely mitigation is essential.
Milestone
Comments
robotlolita
added
the
s:2 critical
robotlolita
added a commit
that referenced
this issue
Oct 3, 2021
This adds the checks for construction and projection capabilities back to Crochet. The rule is that these capabilities are only available for the defining package---but here we run into a problem: intrinsic types have no packages! Still, trusted packages need to manipulate these intrinsic types and provide a view to them. The temporary solution this PR adds is to skip intrinsic capability checks for trusted packages---but the trusted base for Crochet is too big currently (#24), mostly as a result of native code being unsafe to load right now. This shouldn't be too much of a problem yet because intrinsic types have no real power. This fixes #14.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Crochet's entire set of security guarantees rely on being able to control which packages have access to which types, as well as what they can do with these types. Types represent capabilities. But there are some more fine-grained capabilities in a type: using a type has different security implications from constructing a type or projecting fields from a type. That's why Crochet defines these as distinct capabilities.
Capabilities are handled at a "package" level. So packages define a trust boundary. In the specified semantics, constructing and projecting capabilities are granted to the defining package. Meaning that if package A defines a type T, then only package A is able to use
new TorTValue.field. This is currently unchecked, which leads to these expressions succeeding outside of A as well.The text was updated successfully, but these errors were encountered: