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

Support for a more flexible GPG auth model #376

Closed
flammit opened this issue Mar 31, 2018 · 5 comments
Closed

Support for a more flexible GPG auth model #376

flammit opened this issue Mar 31, 2018 · 5 comments

Comments

@flammit
Copy link
Collaborator

flammit commented Mar 31, 2018

Currently there is a single gpg keyring that is used to determine which keys are trusted in a Heads installation. Unfortunately, there are now different ways gpgv is used in init:

  1. Verify when booting from local disks that the kexec config valid
  2. Verify when booting from an ISO that is valid

In the future, there will probably be additional uses:

  1. Validate access to the recovery shell (as in Impose Access Restriction to the Recovery Shell #361)
  2. Validate normal boot procedure with 2FA
  3. Decrypt the TPM-sealed luks disk key (instead of user-provided password)

It seems like maintaining a few key rings would be sufficient to cover a wide range of cases:
/.gnupg/user/: valid sigs to do anything in Heads
/.gnupg/admin/: additional valid sigs to access a recovery shell to wipe/re-provision hardware (but not access user's key material)
/.gnupg/distro/: additional valid sigs to ISO boot

On a standard reproducible build, Heads would have empty user and admin ring, and the distro ring would contain whatever standard distro keys are available (e.g. qubes, tails, alpine, etc.). An installer could then use cbfstool / #357 to add a public key into admin or necessary public key and private key stubs to user.

@osresearch @tlaurion @zaolin @kakaroto @kylerankin thoughts?

@tlaurion
Copy link
Collaborator

tlaurion commented Mar 31, 2018

I love it. I think it would do the job entirely and fits all use cases.

@kakaroto
Copy link
Contributor

I think it's a great idea as well. I vote yes.

@tlaurion
Copy link
Collaborator

tlaurion commented May 5, 2018

Key installation doc here

@tlaurion
Copy link
Collaborator

tlaurion commented May 7, 2018

And integrated into ash_history here

@tlaurion
Copy link
Collaborator

tlaurion commented Aug 3, 2018

@flammit & @osresearch : This was merged and can be closed, no?

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

3 participants