Skip to content
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

Improve EAR Policies #602

Open
fitzthum opened this issue Nov 27, 2024 · 0 comments
Open

Improve EAR Policies #602

fitzthum opened this issue Nov 27, 2024 · 0 comments

Comments

@fitzthum
Copy link
Member

As of today most people do not use very sophisticated or meaningful policies for the KBS or AS.

With the introduction of EAR, we have a more clear framework for how these policies should work. Let's introduce some new policies and tests to really flesh this out.

First, we have a default EAR AS policy. This should generate a trust vector for each platform assuming that the guest is a coco podvm. Currently we have a basic version of this, but we should expand it to support all platforms and introduce a test that actually exercises it, preferably with real hw. I also want to change the logic of the policy a little bit to not use the min function.

The basic idea of the default policy is to map fields in the hw evidence to reference values. This allow us to calculate a few different trust claims which cover the hw, the configuration of the hw, and the binaries separately. This mapping captures the way that the TCB is measured. We could also create a policy for standard VMs, although there is a lot of variety in how these are measured.

We should also update the KBS policy. Currently we mainly use policies that allow all resources or deny all resources. We also have a policy that allows all resources as long as you aren't using the sample attester. These policies aren't really related to the content of the token.

We should create some more sophisticated policies that actually make sure the EAR token isn't contraindicated (this will probably mean populating some reference values for our tests). For testing we could also check that the EAR token has a valid hw and config but not worry about the binaries or something like that. Maybe we should also have examples of how a policy can check values in the init-data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant