Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
WIP WIP WIP -- not tested Let's try a different approach to expressing complex policies: - Policies as restricted bash scripts that can do very little besides evaluate TPM policies, and which are invoked via... - ...a driver script, `sbin/tpm2-policy`, that sets up the environment for running the policy, and takes optional additional artifacts to make available to the policy. - Constant artifacts would be things like: - signer keys for `policysigned` and `policyauthorize` - signer key names for `policyticket` and such - anything else you can imagine Non-constant artifacts would be things like: - saved object context files for signer keys for `policysigned` and `policyauthorize` - tickets from `verifysignature`, `policysecret`, and `policysigned` - timeout files - anything else you can imagine all of which can be written only in `.` / `$PWD`. - The policy scripts would run in the following environment: - a temp dir as the current directory, with `$TMPDIR` set to `$PWD` and in which all the necessary artifacts, including the policy script itself, shall have been placed - various TPM2_POLICY... env vars, mainly TPM2_POLICY_SESSION - `$PATH` set to have just two paths: an `rbin` (see below), and the `$PWD`/`$TMPDIR` itself into which the policy script will have been copied (this will allow the policy script to implement different sub-policies selected by its arguments by executing itself, possibly through the `rbin/policyor` wrapper). - The "rbin" directory in the PATH for the execution of policy scripts, with: - wrappers for all the tpm2_policy... commands - the wrapper for tpm2_policyor is a bit special, naturally - wrappers for tpm2_loadexternal and tpm2_verifysignature, and possibly others - links to or wrappers of a handful of useful system commands like `sha256sum`, `xxd`, `dc`, `bc`, `jq`, etc. - a wrapper around `xxd` and `cat` for creating files from stdin so that artifacts can be embedded as here documents in the script This way policies get all the expressive power of bash, and access to all the functionality of tpm2-tools' policy commands. TBD: - Test, debug, test, ... - Add rbin wrappers for importing duplicated keys (so they can provide authValues discretely!). - Maybe allow execution of `sbin/tpm2-recv` by linking it from the rbin? - Add sample policies that are interesting, like using a combination of `policysigned` and `policyauthorize` and `curl` (outside the policy script) to execute an external script that varies at runtime, or policies that use different passwords for N different users, or which use `policysigned` to let some other entity authenticate N different users (using `policyRef` to name them, say), policies requiring golden PCRs OR external policy, etc. Showcase `policyor`! It'd be very nice to be able to have a policy like this: (golden PCRs && user authValue) || (admin authValue OTP && NV revocation of OTP index) || (superadmin authValue) || ($policy_containing_policy_signed && policyauthorize_of_it) Perhaps with multiple superadmin authValues via `policyor`. Such a policy would allow a laptop to boot normally with a user password, and after emergency updates boot with an admin OTP, or after any mishaps via a superadmin password, or with a separate policy that blesses the current PCRs as golden. Such a policy could be used for sealing an NV index, or it could be set on local storage keys encrypted to the TPM's EKpub via `sbin/tpm2-send`, allowing for unattended server booting post-attestation, or attended server booting post-mishap (if the encrypted assets get stored "in the clear").
- Loading branch information