-
Notifications
You must be signed in to change notification settings - Fork 88
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
[RVPS] RVPS Update Design #350
Comments
It seems like one of the main concrete suggestions here is to update the RVPS to allow reference values to be grouped in terms of the so-called Target Environment. This seems like a good idea, but I"m still a bit fuzzy on how the RVPS should be used in practice. Some pieces that I don't quite understand yet include what a policy that uses reference values should actually look like, how the the manifest should actually be generated, etc. |
About the manifest
I am not sure if it makes sense overall. |
At the moment, in rego policies, we are able to express a group of values and perform policy assertions on them ( Now the problem, if I understood correctly: (groups of) reference values are managed by a different persona than the persona who manages the policy and they shouldn't be coupled. questions:
|
Partially yes. Sorry for my overlook for the starting of this question. One idea is what you said
Yes
This is a good question. There are two parts
Convenience for user experience. Even for me now it is hard to write an expected policy.
Abstractly speaking, a // This is a policy
{
"TE": ["TE_1", "TE_2"], // This evidence must apply to these TEs
"claims": {
"tdx.quote.header.version": {"equal": 4}, // equal operand
"tdx.quote.body.tcb_svn": {"greater-than": 12}, // comparation operand
"tdx.quote.body.xfam": {"in": ["0x0", "0xff"]}, // set operand
}
} However, I admit these are just my current thoughts and could be corrected. |
Maybe we should try to come up with examples of exactly what the end-to-end flow would look like. Ultimately the goal is that users should be able to provision the AS with reference values and some sort of policy as easily as possible. I am wary of creating a new convention for expressing the policy, but I do think the current OPA implementation doesn't quite make sense. Most of the time, the policy will be the same. It's really the selection of reference values that are most significant. In the current implementation we have tons of flexibility and expressiveness for specifying the policy, but almost none for specifying the reference values. One thing that might help the situation would be if we provided a better default policy. We already have one that attempts to compare the claims map to the reference values, but this doesn't allow for some of the more complex comparisons that @Xynnn007 mentions (i.e. a > b). We could try to come up with a more detailed policy that defines these requirements for all the different platforms. Obviously this wouldn't work for every possible situation, but it might help some users not need to write a policy at all. On a semi-related note, we currently return the reference values from the AS as part of the AS Token. Is this a good idea? It makes the token a lot larger. If the token is issued, then presumably the claims maps is valid. I'm not really sure what we envisioned people doing with this info and maybe there is a chance that it could leak something. |
Totally agree. The limit we are facing now is that we do not have enough reference values that can be selected to configure a policy. I believe after we realize the artifact publishment together with CoCo-signed reference values, the situation will be better and we can provide a guide for users to quick start with standard CoCo components.
Yes. The default policy now actually provide only one ability: if any reference data is provided, compare that with the one in parsed claims. Except for that, nothing else is defined. So this seems tightly coupled with reference values from RVPS. By default, no reference value will be set inside RVPS. So the default setting is -- do nothing : | In some cases, users might not want to configure or use RVPS but prefer to configure some reference values into policy manually. So based on such an observation, I gradually realize that an intermediate expressing might help. Just like container-image-policy we are using, they are straightforward and could be extended by adding new rule types any time. Some basic rule type will not involve query well-defined reference value manifest inside RVPS, but just do logiccal/set/numerical operations and their nested operations. But, let's see.
Nice point. Current implementation like this ensures the token itself could ensure the integrity of reference values used to verify -- as mentioned the default policy just tell to use reference values got from RVPS to compare, but not tell what reference values are. If we have
We can get rid of the current reference values fields from the token. As the hash of the policy could ensure the integrity of the policy, and the policy contains the manual reference values, logic and reference value manifest ids. |
I think to start with it's better to provide OPA policy examples, including a sane default policy that works for common use cases. |
Currently, we have Reference Value Provider Service (RVPS) as a black box aiming to provide the following functionalities
register_reference_value(manifest)
Receive different format of reference value manifests, e.g. Sample format, in-toto (developing), CoRIM (TBD) and store the related reference valuesquery_reference_value(claim_id)
Provide a querying API for users e.g. attestation service to query reference value to a specific keyThe reference value inside the RVPS are some key-value pairs. The key is a measurement claim name, such as
mr_td
for TDX andmeasurement
for SNP.The value is the reference values of that field.
@thomas-fossati has raised a core issue named compound reference value problem upon current design.
The concrete model is described here
Thus, a new concept name
Target Environment (TE)
is brought as defined in RATS.A reference value can comprise one or more measurement claims, this means that only if the all claims
in the reference value and TE's measurements are matched altogether, the verification against the reference value
succeeds. A reference value applies to a given TE.
Reference values can be provided in "manifests" comprising one or more reference values.
The updated RVPS will update the API like the following
register_reference_value(manifest)
will not change.query_reference_value(claim_id)
will be updated toquery_reference_value(TE_id)
. This means a set of reference values will be indexed byan id of TE. The result reference values should be matched altogether.
Thus we need some related work along with the road.
TE_id
from a given reference value manifest.For example, a security version number field is greater than a specific number. We might also do some change to facilitate the current OPA integration in CoCoAS.
Roadmaps & Thoughts
The text was updated successfully, but these errors were encountered: