[contribution] TPM2-TOTP

[JarrahG]

The problem you're addressing (if any) QubesOS currently has no method for AEM like boot integrity attestation on UEFI or TPM 2.0 systems. This package, along with some configuration could form the start of such a solution.

Where is the value to a user, and who might that user be? This package provides a relatively simple method for creating a static root of trust in the TPM on boot. Using this (if properly configured), a user can verify that the firmware, bootloader and kernel have not been modified. This package forms the core of this function.

Describe alternatives you've considered QubesOS AEM. However, this system supports neither UEFI nor TPM 2.0

Relevant documentation you've consulted https://www.qubes-os.org/doc/anti-evil-maid/

Package A first draft of the package can be found here: https://github.com/JarrahG/Qubes-TPM2-TOTP

This is my first time contributing a package to Qubes. I'm not exactly sure how to integrate it with the Qubes build system. Any advice here would be greatly appreciated.

The upstream of the package is located here: https://github.com/tpm2-software/tpm2-totp

[andrewdavidwong]

Thank you for your contribution!

This is my first time contributing a package to Qubes. I'm not exactly sure how to integrate it with the Qubes build system. Any advice here would be greatly appreciated.

Please see Package Contributions for detailed information.

[andrewdavidwong]

Assigning to @marmarek (potentially to be reassigned) for initial review.

[JarrahG]

Thanks Andrew. I've been following that procedure. I'm just unsure whether my modifications to the skeleton repository content is correct/will work with the build system.

Please note that the package is still a work in progress. For example, I still need to fix automated source verification. However, the RPM output does build and work within QubesOS.

[andrewdavidwong]

Thanks Andrew. I've been following that procedure. I'm just unsure whether my modifications to the skeleton repository content is correct/will work with the build system.

Ah, I see what you're saying. Perhaps @fepitre might be able to comment on that?

Please note that the package is still a work in progress. For example, I still need to fix automated source verification.

Oh, ok. In that case, I'll update the status and reassign this to you.

[fepitre]

Thanks Andrew. I've been following that procedure. I'm just unsure whether my modifications to the skeleton repository content is correct/will work with the build system.

Ah, I see what you're saying. Perhaps @fepitre might be able to comment on that?

Sure I'll have look to help in the packaging.

[JarrahG]

Thanks for the review Fepitre. I believe have it sorted now. Only point of uncertainty is the gpg check. Worst case, I can always tear that out and verify with the SHA512 only. Otherwise, this should now be ready to go.

[fepitre]

For gpg check you can take look at https://github.com/QubesOS/qubes-linux-kernel/blob/51dbb9d3989f8c2840b2f3156d3fd38efa0d3e0f/Makefile#L72 with the linux kernel example. Adapt it in your case and that should be good and better than always computing shasum for every release. In a lot of packages, we use Fedora provided shasum to check and create new one but gpg verification is better.

[JarrahG]

I think I have that sorted now. Thanks.

[JarrahG]

@andrewdavidwong I believe this is ready for review. Could you please remove the "in progress" label. Thanks.

[andrewdavidwong]

@andrewdavidwong I believe this is ready for review. Could you please remove the "in progress" label. Thanks.

Ok, great! Assigning to @marmarek (potentially to be reassigned) for initial review.

[dylangerdaly]

@JarrahG I can't see your commits, I'd very much like to try out your changes.

[JarrahG]

Interesting, I can see them before logging in: https://github.com/JarrahG/Qubes-TPM2-TOTP/commits/master

On the note of the conversation in the above linked issue (6081), this will not replace AEM, but may form part of a similar solution supporting UEFI/TPM 2.0.

[dylangerdaly]

Oh my bad, I didn't read

I'm not exactly sure how to integrate it with the Qubes build system

So this package will generate an RPM that one could install onto dom0? What PCRs are being used to build the policy?

this will not replace AEM, but may form part of a similar solution supporting UEFI/TPM 2.0.

Fair enough, there looks to be a lot more to take into consideration.

[JarrahG]

So this package will generate an RPM that one could install onto dom0? What PCRs are being used to build the policy?

The default values are quite basic: 0, 2, 4. The expectation will be to build a default config as another package which will include the Grub bits and script filling other PCRs in the same way AEM does. But one step at a time. More details here: https://github.com/tpm2-software/tpm2-totp

Fair enough, there looks to be a lot more to take into consideration.

It's a complex problem. There is plenty to do on it.

[JarrahG]

I've attempted to test this package with qubes builder, but I'm not sure whether my use of the builder or the package is at fault. What I have done is used https://github.com/QubesOS-contrib/qubes-contrib-configs/blob/master/example-configs/qubes-os-contrib-r4.1.conf as the config for qubes-builder, substuting this package for the contrib list. The error I get is below:

CACHEDIR=/home/user/qubes-builder/cache/fc32 CHROOT_DIR=/home/user/qubes-builder/chroot-dom0-fc32  \
    -v -r /home/user/qubes-builder/qubes-src/builder-rpm//mock-fedora.cfg \
    --resultdir=/home/user/qubes-builder/chroot-dom0-fc32//home/user/qubes-src/TPM2-TOTP/pkgs/dom0-fc32 \
    --define "dist .fc32" --define "fedora 32" --define "dist .fc32" --define "fedora 32"  \
     --dnf --enablerepo=qubes-current --dnf --enablerepo=qubes-current \
    --buildsrpm --spec rpm_spec/tpm2-totp-dom0.spec --sources /home/user/qubes-builder/chroot-dom0-fc32/home/user/qubes-src/TPM2-TOTP
sudo: unrecognized option '--resultdir=/home/user/qubes-builder/chroot-dom0-fc32//home/user/qubes-src/TPM2-TOTP/pkgs/dom0-fc32'

Obviously there is supposed to be a command between sudo and the rest of the arguments, but I can't figure out where that command should be coming from.

[fepitre]

I've attempted to test this package with qubes builder, but I'm not sure whether my use of the builder or the package is at fault. What I have done is used https://github.com/QubesOS-contrib/qubes-contrib-configs/blob/master/example-configs/qubes-os-contrib-r4.1.conf as the config for qubes-builder, substuting this package for the contrib list. The error I get is below:

CACHEDIR=/home/user/qubes-builder/cache/fc32 CHROOT_DIR=/home/user/qubes-builder/chroot-dom0-fc32  \
  -v -r /home/user/qubes-builder/qubes-src/builder-rpm//mock-fedora.cfg \
  --resultdir=/home/user/qubes-builder/chroot-dom0-fc32//home/user/qubes-src/TPM2-TOTP/pkgs/dom0-fc32 \
  --define "dist .fc32" --define "fedora 32" --define "dist .fc32" --define "fedora 32"  \
   --dnf --enablerepo=qubes-current --dnf --enablerepo=qubes-current \
  --buildsrpm --spec rpm_spec/tpm2-totp-dom0.spec --sources /home/user/qubes-builder/chroot-dom0-fc32/home/user/qubes-src/TPM2-TOTP
sudo: unrecognized option '--resultdir=/home/user/qubes-builder/chroot-dom0-fc32//home/user/qubes-src/TPM2-TOTP/pkgs/dom0-fc32'

Obviously there is supposed to be a command between sudo and the rest of the arguments, but I can't figure out where that command should be coming from.

I'll take a look tomorrow.

[marmarek]

This looks like missing 'mock' package - install it first.

[JarrahG]

mock was the issue, thanks.

Next issue is that it does not download the source tarball. I can't see much difference between tpm2-totp's Makefile and others in the contrib repo, but tpm2-totp's does not pull the tarball in either get-sources or get-sources-extra