Skip to content

Determine the hash value of a policy

We have seen in the last assignment, that each policy (a.k.a. session) has a hash value. This hash value is returned when one creates or updates a policy. We will see that one needs the hash value to update a policy. Sometimes one might forget to store the hash value, or due to an error, the hash value is lost, or somebody else has changed the policy.

The reason that one has to declare a predecessor in a policy is to be able to track and synchronize changes of a policy. With the help of the predecessor field, one can determine a linear history of all previous policies with the same name. This is important in case one wants to check if other policies had been granted access to a secret in the past or which MRENCLAVEs had access to secrets. Via the CAS REST API, one can then query the past policies - if one has read access to the policies.

The predecessor field is also used to synchronize updates to a policy. If multiple entities might concurrently update a policy, the predecessor field can be used to ensure that no other entity has modified the policy in the meantime. A typical workflow is as follows:

  1. read the current policy,
  2. determine the hash of the current policy, say, it is $PREDECESSOR,
  3. modify the policy and define predecessor to be $PREDECESSOR, i.e.,
predecessor: $PREDECESSOR
  1. update the policy

If another entity has modified the policy between step 1. and step 4., the hash will change and hence, the predecessor will change. In this case, the update of the policy will fail. The writer has to retry steps 1 to 4.

Task 1

Write a script in your favorite scripting language that performs the following steps:

  • Retrieve the namespace policy that you created in the last assignment
  • Compute the hash of this policy using scone session verify.
  • Write out an updated state file state.env that contains the name of the namespace and its current hash of the policy.

Task 2

Verify that you computed the correct hash value by reading a policy using the policy name and the hash of the policy. In this case, the policy name is the name of your namespace. The hash is the value that you retrieved in task 1.

Background

To compute the hash of an existing policy, we can first retrieve the policy using scone session read and store this in a file. We pass this file to scone session verify. The command scone session verify computes the hash value of the given policy file.

To retrieve a session via the SCONE CAS REST API, you need a client certificate that permits you read access to the session. Using the standard curl tool, one can specify a client certificate with the option --cert <FILE>. Since we created the session with scone CLI, by default only the key pair of the scone CLI can be used to retrieve the session content. In case, the scone CLI itself is not protected, we can extract the CLI as follows:

  • Read the scone configuration file stored in $HOME/.cas/config.json.
  • Extract the value of the key identity. You might want to use a tool like jq to extract the value of this key.

To retrieve the policy from CAS, we need the certificate of the CAS instance and a client certificate. We can retrieve this certificate using scone cas show-certificate as we have already seen in assignment 1.

The URL that we need to retrieve the session is as follows: https://cas:8081/v1/sessions/${NS}?hash=${COMPUTED_NAMESPACE_HASH}. Where $NS contains the name of the policy and $COMPUTED_NAMESPACE_HASH its hash.

Solution

A solution for this task for bash is available in assignment 3](https://github.com/scontain/Exercise/tree/main/Exercise3).

Screencast

Troubleshooting

  • Please have a look at the troubleshooting hints from the previous assignments. If you experience any additional issues, please let us know via email. We will add the issue and a proposed solution to this troubleshooting section.