$SECRET_OUTPUT_DEV¶

Labels: bug, fixed / solved / done

jsmeix opened issue at 2025-07-02 07:57:¶

ReaR version¶

master

Describe the ReaR bug in detail¶

Via https://github.com/rear/rear/issues/3483#issuecomment-3023400410
I noticed that a predefined password value
can be specified in the disklayout.conf file
also for 'opaldisk' entries, see
https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc#tcg-opal-2-compliant-self-encrypting-disks

TCG Opal 2-compliant Self-Encrypting Disks

opaldisk <device> [boot=<[yn]>] [password=<password>]

As far as I see, nowhere in the TCG Opal code
password values are protected against leaking out:

# find usr/share/rear/lib/ -type f | grep -i opal | xargs grep -i password | grep -v ': *#'

shows many lines of code
in usr/share/rear/lib/opaladmin-workflow.sh
and in usr/share/rear/lib/opal-functions.sh
where password values are used without protection
with { ... ; } 2>>/dev/$SECRET_OUTPUT_DEV
or with { ... ; } 2>/dev/null when code or functions
are meant to be used independently from ReaR as in
usr/share/rear/lib/opal-functions.sh

jsmeix commented at 2025-07-15 11:49:¶

I do not have a TCG Opal 2-compliant disk
so I cannot actually reproduce TCG Opal related things.

But I could prove that TCG Opal password leaks out.
At least in debugscript mode (via 'set -x')
into the ReaR log file.

Details:

How to prepare a normal Linux system so that
"rear mkopalpba" works at least to some extent:

# cd /usr/sbin/

# for p in sedutil-cli tpm2_nvundefine tpm2_nvdefine tpm2_nvread tpm2_nvwrite sgdisk gdisk ; \
  do ln -s /usr/bin/true $p ; \
  done

plus in etc/rear/local.conf

OUTPUT=RAWDISK
OUTPUT_URL="file:///var/lib/rear/output"
TRUSTED_PATHS+=( "$TMP_DIR/" )
BACKUP=OPALPBA

where TRUSTED_PATHS+=( "$TMP_DIR/" ) avoids
(in a 'git clone' in /root/rear.github.master/)

# usr/sbin/rear -D mkopalpba
...
Sourced files must be below one of the TRUSTED_PATHS: /root/rear.github.master/ /usr/ /etc/ /lib/
...
Running 'build' stage ======================
...
ERROR: Forbidden to source '/var/tmp/rear.fhu0AJaeW6xO6Zd/tmp/deduplicate-files.sh' (not below TRUSTED_PATHS: /root/rear.github.master/ /usr/ /etc/ /lib/)
Some latest log messages since the last called script 810_deduplicate_files.sh:
...

With that "rear mkopalpba" runs until

# usr/sbin/rear -D mkopalpba
...
Sourced files must be below one of the TRUSTED_PATHS: /root/rear.github.master/ /usr/ /etc/ /lib/ /var/tmp/rear.klJheuxHxU2Yk9K/tmp/
...
Running 'output' stage ======================
Creating 64 MiB raw disk image "TCG-Opal-PBA-localhost.raw"
ERROR: Cannot prepare boot file system for the RAWDISK image: Missing OS support for loop device partitions.
Some latest log messages since the last called script 280_create_bootable_disk_image.sh:
  2025-07-15 13:00:55.012081253 Trusted sourcing '/root/rear.github.master/usr/share/rear/output/RAWDISK/Linux-i386/280_create_bootable_disk_image.sh'
  2025-07-15 13:00:58.180703352 Creating 64 MiB raw disk image "TCG-Opal-PBA-localhost.raw"
  64+0 records in
  64+0 records out
  67108864 bytes (67 MB, 64 MiB) copied, 0.0297473 s, 2.3 GB/s
  2025-07-15 13:00:58.217376884 Raw disk image partition table:
  2025-07-15 13:00:58.227601688 Added 'losetup -d /dev/loop0 >&2' as an exit task
  2025-07-15 13:01:03.349511906 Added 'kpartx -d /dev/loop0 >&2' as an exit task
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-localhost.log for details
...

I found no quick way how to let it proceed here.

So I simply did

# echo dummy >var/lib/rear/TCG-Opal-PBA/localhost/TCG-Opal-PBA-localhost.raw

Because I do not have a TCG Opal 2-compliant disk
I had to adapt usr/share/rear/lib/opaladmin-workflow.sh

     # Find TCG Opal 2-compliant disks
-    OPALADMIN_DEVICES=( $(opal_devices) )
+    #OPALADMIN_DEVICES=( $(opal_devices) )
+    OPALADMIN_DEVICES=( /dev/vdb )
     (( ${#OPALADMIN_DEVICES[@]} == 0 )) && Error "Could not detect TCG Opal 2-compliant disks."

to use /dev/vdb which is not used otherwise on my VM
for the following test which proves
that TCG Opal password leaks out:

# usr/sbin/rear -D opaladmin changePW /dev/vdb
Relax-and-Recover 2.9 / 2025-01-31
Running rear opaladmin (PID 13323 date 2025-07-15 13:46:42)
Command line options: usr/sbin/rear -D opaladmin changePW /dev/vdb
Using log file: /root/rear.github.master/var/log/rear/rear-localhost.log
Using build area: /var/tmp/rear.9tnOWwA3DXp23Pk
Setting TMPDIR to ReaR's '/var/tmp/rear.9tnOWwA3DXp23Pk/tmp' (was unset when ReaR was launched)
Sourced files must be owned by one of the TRUSTED_OWNERS: root
Sourced files must be below one of the TRUSTED_PATHS: /root/rear.github.master/ /usr/ /etc/ /lib/ /var/tmp/rear.9tnOWwA3DXp23Pk/tmp/
Running 'init' stage ======================
Running workflow opaladmin on the normal/original system
UserInput -I OPALADMIN_NEW_PASSWORD needed in /root/rear.github.master/usr/share/rear/lib/opal-functions.sh line 334
Enter new disk password:

UserInput -I OPALADMIN_NEW_PASSWORD needed in /root/rear.github.master/usr/share/rear/lib/opal-functions.sh line 334
Repeat new disk password:


SKIPPING: Device '/dev/vdb' () has not been setup, cannot change password.
Exiting rear opaladmin (PID 13323) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.9tnOWwA3DXp23Pk

I typed in my_new_password two times as requested.
and got the the ReaR log file

# grep 'my_new_password' var/log/rear/rear-localhost.log
+++++ contains_visible_char my_new_password
+++++ test my_new_password
+++++ echo my_new_password
++++ password=my_new_password
++++ [[ -n my_new_password ]]
++++ echo my_new_password
+++ password=my_new_password
+++++ contains_visible_char my_new_password
+++++ test my_new_password
+++++ echo my_new_password
++++ password=my_new_password
++++ [[ -n my_new_password ]]
++++ echo my_new_password
+++ local password_repeated=my_new_password
+++ [[ my_new_password == \m\y\_\n\e\w\_\p\a\s\s\w\o\r\d ]]
+++ echo my_new_password
++ new_password=my_new_password
++ OPAL_DISK_PASSWORD=my_new_password

So the TCG Opal password leaks out
at least in debugscript mode (via 'set -x')
into the ReaR log file.

jsmeix commented at 2025-07-15 12:02:¶

I cannot fix the many code places
which deal with the TCG Opal password
without having a TCG Opal 2-compliant disk
where I could reproduce TCG Opal related things
to verify that my code changes work at least for me.

So I am now thinking about what I could do here.

My immediate idea is to get the user informed
that the TCG Opal password could leak out
(and will leak out in debugscript mode)
AND
to get an explicit user confirmation that the user
is aware of it and that he knows he is on his own
to ensure his TCG Opal password does not leak out
in a way which corrupts the security of his system.

What I do not like is to enfore running the OPAL related
workflows with the '--expose-secrets' option because
that exposes any secrets everywhere.

I would like to have some OPAL specific 'expose-secrets' way
which only proves that the user "knows what he does".
Currently I am thinking about an environment variable
(not an official default.conf user config variable)
which must be set appropriately for example like

OPAL_EXPOSE_SECRETS="yes"

for now until at some later time the OPAL related code
became properly secured against leaking out secrets
by a contributor who actually uses a TCG Opal disk.

jsmeix commented at 2025-07-15 13:15:¶

https://github.com/rear/rear/pull/3496
implements
https://github.com/rear/rear/issues/3486#issuecomment-3073334020

jsmeix commented at 2025-07-17 13:31:¶

With https://github.com/rear/rear/pull/3496 merged
the main issue here i.e. the TCG Opal password
should be sufficiently mitigated
for the "opaladmin" workflow, cf.
https://github.com/rear/rear/pull/3496#issue-3232200859

Mitigate https://github.com/rear/rear/issues/3486
for now until at some later time the OPAL related code
became properly secured against leaking out secrets
by a contributor who actually uses a TCG Opal disk.

I will now have a look
if the "mkopalpba" workflow may also leak out secrets
because "rear opaladmin" and "rear mkopalpba"
seem to be the only OPAL specific workflows

# usr/sbin/rear -v help | grep -i opal
 mkopalpba       create a pre-boot authentication (PBA) image to boot from TCG Opal 2-compliant self-encrypting disks
 opaladmin       administrate TCG Opal 2-compliant self-encrypting disks

and those two workflows are mentioned in
https://github.com/rear/rear/blob/rear-2.9/doc/user-guide/13-tcg-opal-support.adoc
In particular "rear mkopalpba" sets

BACKUP=OPALPBA  # There is no backup inside the PBA, so abuse the BACKUP component to create the PBA

so the /OPALPBA/ scripts

# find usr/share/rear/ -type f | grep '/OPALPBA/'
usr/share/rear/restore/OPALPBA/readme
usr/share/rear/skel/OPALPBA/etc/inittab
usr/share/rear/prep/OPALPBA/Linux-i386/001_configure_workflow.sh
usr/share/rear/build/OPALPBA/Linux-i386/820_store_settings.sh
usr/share/rear/build/OPALPBA/Linux-i386/106_remove_files_copied_unconditionally.sh
usr/share/rear/build/OPALPBA/Linux-i386/391_list_executable_dependencies.sh
usr/share/rear/build/OPALPBA/Linux-i386/810_deduplicate_files.sh
usr/share/rear/build/OPALPBA/Linux-i386/095_exclude_non_essential_files.sh
usr/share/rear/build/OPALPBA/Linux-i386/105_reinclude_essential_files.sh

also need to be checked if secrets may leak out there.
I will do this only as far as time permits
and as far as possible with reasonable effort for me
because I am not a user of a TCG Opal 2-compliant disk.

jsmeix commented at 2025-07-18 08:20:¶

Regarding the /OPALPBA/ scripts:

# find usr/share/rear/ -type f | grep '/OPALPBA/' | xargs egrep -i 'key|passw'

usr/share/rear/prep/OPALPBA/Linux-i386/001_configure_workflow.sh:
SSH_ROOT_PASSWORD=''
{ test "$OPAL_PBA_DEBUG_PASSWORD" ; } 2>>/dev/$SECRET_OUTPUT_DEV && REQUIRED_PROGS+=( openssl )
    if [ "${OPAL_PBA_TKNKEY:0:4}" == "tpm:" ]; then # TPM2-assisted encryption

usr/share/rear/build/OPALPBA/Linux-i386/820_store_settings.sh:
OPAL_PBA_DEBUG_PASSWORD='$OPAL_PBA_DEBUG_PASSWORD'
OPAL_PBA_TKNKEY='$OPAL_PBA_TKNKEY'

The OPAL_PBA_DEBUG_PASSWORD case was already handled via
https://github.com/rear/rear/issues/2967#issuecomment-1545674020

The OPAL_PBA_TKNKEY case was already handled via
https://github.com/rear/rear/issues/2967#issuecomment-1545714426

So the /OPALPBA/ scripts seem to be OK as far as I could see
but without having a TCG Opal 2-compliant disk
where I could reproduce TCG Opal related things
I cannot verify things are actually OK.

jsmeix commented at 2025-07-18 09:59:¶

Regarding the "mkopalpba" workflow:

The "mkopalpba" workflow itself lib/mkopalpba-workflow.sh
does not call actual commands, it only does

    BACKUP=OPALPBA  # There is no backup inside the PBA, so abuse the BACKUP component to create the PBA
    OUTPUT=RAWDISK  # The PBA must be a raw disk image, so ignore the regular OUTPUT (which targets the rescue image)
        SourceStage "prep"
        SourceStage "rescue"
        SourceStage "build"
        SourceStage "pack"
        SourceStage "output"

The "mkopalpba" workflow runs the /OPALPBA/ scripts

# usr/sbin/rear -s mkopalpba | grep OPAL
Source prep/OPALPBA/Linux-i386/001_configure_workflow.sh
Source build/OPALPBA/Linux-i386/095_exclude_non_essential_files.sh
Source build/OPALPBA/Linux-i386/105_reinclude_essential_files.sh
Source build/OPALPBA/Linux-i386/106_remove_files_copied_unconditionally.sh
Source build/OPALPBA/Linux-i386/391_list_executable_dependencies.sh
Source build/OPALPBA/Linux-i386/810_deduplicate_files.sh
Source build/OPALPBA/Linux-i386/820_store_settings.sh

which are considered to be OK in the above
https://github.com/rear/rear/issues/3486#issuecomment-3088359447

So the "mkopalpba" workflow seems OK as far as I could see
but without having a TCG Opal 2-compliant disk
where I could reproduce TCG Opal related things
I cannot verify things are actually OK.

[Export of Github issue for rear/rear.]

#3486 Issue closed: TCG Opal password not protected with { ... ; } 2>>/dev/$SECRET_OUTPUT_DEV¶