#3485 PR merged: protect LUKS password from leaking out

Labels: bug, fixed / solved / done

jsmeix opened issue at 2025-07-01 12:41:

jsmeix commented at 2025-07-01 12:55:

How this pull request was tested:

With the changes here I did the same as in
https://github.com/rear/rear/issues/3483#issuecomment-3023400410
but now

RESCUE localhost:~ # rear -D recover
...

RESCUE localhost:~ # grep johannes /var/log/rear/rear-localhost.log
[no output]

so the password does no longer leak out into the ReaR log file

Where the LUKS password still is:

RESCUE localhost:~ # grep johannes /var/lib/rear/layout/disklayout.conf

crypt /dev/mapper/cr_root ... password=johannes
crypt /dev/mapper/cr_swap ... password=johannes

This is unavoidable because I had manually added it there, see
https://github.com/rear/rear/issues/3483#issuecomment-3023400410

and

RESCUE localhost:~ # grep johannes /var/lib/rear/layout/diskrestore.sh

{ echo "johannes" | cryptsetup luksFormat --batch-mode  --type luks1 --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid b37bfd65-b8cd-42cb-b2a7-b3ae772bc2c5 --iter-time 2000 --use-random --force-password /dev/vda2 ; } 2>/dev/null
{ echo "johannes" | cryptsetup luksOpen /dev/vda2 cr_root ; } 2>/dev/null
...
{ echo "johannes" | cryptsetup luksFormat --batch-mode  --type luks1 --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 84838219-dfbe-449b-95df-28f3e177de94 --iter-time 2000 --use-random --force-password /dev/vda3 ; } 2>/dev/null
{ echo "johannes" | cryptsetup luksOpen /dev/vda3 cr_swap ; } 2>/dev/null

I think this is also unavoidable because of how the
optional password=<password> functionality in disklayout.conf
is meant to work so there must be code like

echo "$password" | cryptsetup ...

in diskrestore.sh to implement that functionality.

jsmeix commented at 2025-07-02 08:02:

The above
https://github.com/rear/rear/pull/3485/commits/9152542ed6faa2ff87070056394377cc558d1b06
fixes by-the-way already here a tiny part of what belongs to
https://github.com/rear/rear/issues/3486

jsmeix commented at 2025-07-02 13:02:

I think the current fix in this pull request
is "good enough" at least for now so
@rear/contributors
I would like to merge it tomorrow afternoon
unless there are severe objections.

Later - as time permits - I will think about
if there is a proper generic way
how to implement functionality like

echo "$password" | COMMAND ...

without leaking out the password value with 'set -x'
i.e. without visible evaluating '$password' with 'set -x'.

My immediate idea is to use

COMMAND ... <<< "$password"

On simple commandline with COMMAND 'cat' that seems to work:

# password="my password"

# ( set -x ; echo "$password" | cat -n )
+ echo 'my password'
+ cat -n
     1  my password

# ( set -x ; cat -n <<< "$password" )
+ cat -n
     1  my password

In this test cat -n intentionally shows the password value
to prove that COMMAND got the password value as input.
The point of this test is to avoid that the COMMAND input
gets shown in any case with 'set -x'.

When COMMAND ... <<< "$password" is really a generic way
to avoid that COMMAND input gets shown with 'set -x',
I will implement it via a separated subsequent pull request.

[Export of Github issue for rear/rear.]