AEM - sudo anti-evil-maid-seal failing from dom0 console because setting LABEL is failing

[adrelanos]

Qubes OS version:

R3.2

Affected TemplateVMs:

dom0

---

Steps to reproduce the behavior:

sudo anti-evil-maid-seal

Expected behavior:

No such error or a better error message explaining what is wrong i.e. possible user mistake or hardware bug.

Actual behavior:

Error.

General notes:

https://github.com/QubesOS/qubes-antievilmaid/blob/8d8a941f5647b0082a20b4245859986d3ca45c12/anti-evil-maid/sbin/anti-evil-maid-seal#L23

LABEL=$LABEL_PREFIX${1-$(cat "$SUFFIX_CACHE")}

Does not work for me.

+ set -e -o pipefail
+ shopt -s expand_aliases
+ systemctl start tcsd
+ alias 'plymouth_message=plymouth message --text'
+ source anti-evil-maid-lib
++ LABEL_PREFIX=aem
++ AEM_DIR=/var/lib/anti-evil-maid
++ TPM_DIR=/var/lib/tpm
++ TPMS_DIR=/var/lib/tpms
++ CACHE_DIR=/run/anti-evil-maid
++ SRK_PASSWORD_CACHE=/run/anti-evil-maid/srk-password
++ SUFFIX_CACHE=/run/anti-evil-maid/suffix
++ command plymouth --ping
++ alias plymouth=:
++ alias plymouth_active=false
++ alias message=log
+ trap 'rm -rf "$CACHE_DIR"' EXIT
+ source /etc/anti-evil-maid.conf
++ SEAL='--pcr 13 --pcr 17 --pcr 18 --pcr 19'
++ tpm_z_srk
+ log 'detecting whether SRK is password protected'
+ echo 'tpm_z_srk: detecting whether SRK is password protected'
tpm_z_srk: detecting whether SRK is password protected
+ tpm_sealdata -z
Tspi_Key_CreateKey failed: 0x00000001 - layer=tpm, code=0001 (1), Authentication failed
+ log 'yes, SRK is password protected; resetting dictionary attack lock...'
+ echo 'tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...'
tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...
+ tpm_resetdalock -z
+ Z=
++ cat /run/anti-evil-maid/suffix
cat: /run/anti-evil-maid/suffix: No such file or directory
+ LABEL=aem
+ rm -rf /run/anti-evil-maid

Modified to:

LABEL=$LABEL_PREFIX${1-$(cat "$SUFFIX_CACHE")} || true

Now it's working.

Working meaning, after adding this hack, and another hack #3297, sudo anti-evil-maid-seal showed no more error and I could view my secret at the next reboot. I don't know if this hack was sane or if that hack together with #3297 actually invalidated the protections by AEM.

[phagara]

The -seal script is supposed to be started automatically by the systemd service upon each (even unsuccessful) AEM boot, not manually as you did there (presumably right after running the -install script and without rebooting).

That particular line is trying to derive the filesystem label of the AEM media you booted from -- in this case, there was none and thus it failed. By adding || true at the end and not supplying a positional argument with the desired label suffix to the -seal script, only $LABEL_PREFIX ("aem") got assigned to $LABEL. Coincidentally, as your AEM media did not have a custom suffix, your hack "worked".

TL;DR: reboot after running anti-evil-maid-install and let the system perform sealing (and do not remove the sanity check in #3297 but try to get your measured boot to really work -- make sure you have Intel TXT enabled in bios, suitable SINIT module for your platform downloaded, check txt-stat in dom0, etc... you can find more debugging tips by searching the qubes-users mailing list).

[phagara]

The -seal script is supposed to be started automatically by the systemd service upon each (even unsuccessful) AEM boot, not manually as you did there (presumably right after running the -install script and without rebooting).

That particular line is trying to derive the filesystem label of the AEM media you booted from -- in this case, there was none and thus it failed. By adding || true at the end and not supplying a positional argument with the desired label suffix to the -seal script, only $LABEL_PREFIX ("aem") got assigned to $LABEL. Coincidentally, as your AEM media did not have a custom suffix, your hack "worked".

TL;DR: reboot after running anti-evil-maid-install and let the system perform sealing (and do not remove the sanity check in #3297 but try to get your measured boot to really work -- make sure you have Intel TXT enabled in bios, suitable SINIT module for your platform downloaded, check txt-stat in dom0, etc... you can find more debugging tips by searching the qubes-users mailing list).

[adrelanos]

TL;DR: reboot after running anti-evil-maid-install and let the system perform sealing

I see.

The -seal script is supposed to be started automatically by the systemd service upon each (even unsuccessful) AEM boot, not manually as you did there (presumably right after running the -install script and without rebooting).

I had rebooted several times. I hacked it because debugging by rebooting is an incredible time intense process (due to another bug of USBVM shutdown / killing taking a very long time). Rebooting to try again is very ineffective time wise to debug.

Therefore I was looking for a faster way to debug it - by running it from the running system.

Wishlist solutions:

1. preferred: Do you think you can make the script idempotent, making it possible to run it any time (or after the first reboot) from the running system?
2. better error message

[adrelanos]

TL;DR: reboot after running anti-evil-maid-install and let the system perform sealing

I see.

The -seal script is supposed to be started automatically by the systemd service upon each (even unsuccessful) AEM boot, not manually as you did there (presumably right after running the -install script and without rebooting).

I had rebooted several times. I hacked it because debugging by rebooting is an incredible time intense process (due to another bug of USBVM shutdown / killing taking a very long time). Rebooting to try again is very ineffective time wise to debug.

Therefore I was looking for a faster way to debug it - by running it from the running system.

Wishlist solutions:

1. preferred: Do you think you can make the script idempotent, making it possible to run it any time (or after the first reboot) from the running system?
2. better error message

[phagara]

The problem is, -seal script must see the PCR registers set to the same values as during your future AEM boots, so that it has a known state to seal the secret(s) against. This implies either pre-computing the PCR values and sealing to that or rebooting using the desired tboot/Xen/kernel binaries and configs to have the registers set.

Other than that, it already is as idempotent as possible (the generated sealed secrets will always be different due to encryption nonces, but sealed to the same PCR values and you can re-run it as many times as you want).

[phagara]

The problem is, -seal script must see the PCR registers set to the same values as during your future AEM boots, so that it has a known state to seal the secret(s) against. This implies either pre-computing the PCR values and sealing to that or rebooting using the desired tboot/Xen/kernel binaries and configs to have the registers set.

Other than that, it already is as idempotent as possible (the generated sealed secrets will always be different due to encryption nonces, but sealed to the same PCR values and you can re-run it as many times as you want).

[phagara]

As for the "better error message" variant, we could easily direct the user to pass the AEM media suffix as a positional argument to the -seal script if $SUFFIX_CACHE does not exist (as would be the case with non-AEM boot) and no positional arg was passed.

[phagara]

As for the "better error message" variant, we could easily direct the user to pass the AEM media suffix as a positional argument to the -seal script if $SUFFIX_CACHE does not exist (as would be the case with non-AEM boot) and no positional arg was passed.