Improve cryptographic security and user-friendliness for LUKS volumes #1493
Conversation
Change crypt entry in disklayout.conf: - Remove 'mode' option, absorb its value into 'cipher'. - Remove undocumented 'key' option. - Add options 'key_size' and 'keyfile'. - Document 'password' option. Change default.conf: - Add 'LUKS_CRYPTSETUP_OPTIONS' variable with cryptographcially up-to-date default settings. Auto-detect 'key_size' from original LUKS volume and apply as cryptsetup option '--key-size'. Auto-detect 'keyfile' option, enable unattended (password-less) decryption via temporary keyfile without leaking original keyfiles on rescue medium, securely re-assign keyfiles after restore.
|
@OliverO2 only FYI @gozora |
|
@OliverO2 original keyfiles should have been restored from the backup it means that with this pull request nothing secret |
|
@jsmeix
Also see this comment in 160_include_luks_code.sh. When you have encrypted disks and you leak secrets onto the unencrypted rescue medium it is like building an expensive underground bank vault and then putting the key into a tin box on your desk. So I just went the extra mile to avoid this. I agree with #1472 (comment) and below. My next task is actually to provide a ReaR option to encrypt ssh keys which
The idea incorporates asking the user for an initial recovery master password (resembling #1444 (comment)), although I would not recommend putting this into configuration files. |
|
@OliverO2 As you can also see in SSH_ROOT_PASSWORD="rear" still "just works" to "just get" ssh access into the recovery system |
There was a problem hiding this comment.
First of all let me apologize for taking me so long to reply to this PR, but I've somehow missed it :-(.
For me implementing automatic volume unlocking is somehow politic decision, and as I don't like politics I let @schlomo decide whether something like this should or should not be implemented. (c.f. #1444 (comment)).
@OliverO2 this PR is broken for systems that don't use automatic unlocking of volumes (which is completely valid setup)
As man crypttab states:
The third field specifies the encryption password. If the field is not present or the password is set to "none" or "-", the password has to be manually entered during system boot. Otherwise, the field is interpreted as a absolute path to a file containing the encryption password. For swap encryption, /dev/urandom or the hardware device /dev/hw_random can be used as the password file; using /dev/random may prevent boot completion if the system does not have enough entropy to generate a truly random encryption key.
I've tested your PR with following crypttab:
luks-0ef6a905-e6a2-4a3d-92ab-caa541f9306a UUID=0ef6a905-e6a2-4a3d-92ab-caa541f9306a none
Cdata1 UUID=acd42bd9-53d0-41b5-8d31-f03d320d2b75 /root/keyfile1 luks
With following result during recovery:
++ echo '2017-09-23 21:18:05.163296443 Re-assigning keyfile none to LUKS device /dev/sda2'
2017-09-23 21:18:05.163296443 Re-assigning keyfile none to LUKS device /dev/sda2
+++ basename none
++ temp_keyfile=/tmp/LUKS-keyfile-none
++ '[' -f /tmp/LUKS-keyfile-none ']'
++ target_keyfile=/mnt/local/none
++ '[' -f /mnt/local/none ']'
+++ dirname /mnt/local/none
++ mkdir -p /mnt/local
++ cp -p /tmp/LUKS-keyfile-none /mnt/local/none
++ rm /tmp/LUKS-keyfile-none
++ StopIfError 'Could not restore keyfile none for LUKS device /dev/sda2 from temporary keyfile'
++ (( 0 != 0 ))
++ LogPrintError 'none was not restored - LUKS device /dev/sda2 has been assigned a new keyfile'
++ Log 'none was not restored - LUKS device /dev/sda2 has been assigned a new keyfile'
As you might have guessed, this resulted to unbootable OS.
V.
| # may set LUKS_CRYPTSETUP_OPTIONS="--iter-time 2000 --use-urandom" instead, but be aware that this produces a | ||
| # low-quality master encryption key. For details, see the cryptsetup(8) manual page. | ||
| LUKS_CRYPTSETUP_OPTIONS="--iter-time 2000 --use-random" | ||
|
|
There was a problem hiding this comment.
Restoring virtual machines lacks entropy, so it might happen that during restore of VM ReaR will just "sit and wait" ..
There was a problem hiding this comment.
True. Secure by default, but may not cover every use case. User should re-configure LUKS_CRYPTSETUP_OPTIONS in these cases. Whether it's a good idea to use encryption inside entropy-lacking environments is another question.
| # 'finalize' stage. | ||
| # The scheme for generating a temporary keyfile path must be the same here and in the 'finalize' stage. | ||
| keyfile="${TMPDIR:-/tmp}/LUKS-keyfile-$(basename $keyfile)" | ||
| dd bs=512 count=4 if=/dev/urandom of="$keyfile" |
There was a problem hiding this comment.
You've stated in default.conf:
but be aware that this produces a
low-quality master encryption key. For details, see the cryptsetup(8) manual page.
I think that having disks encrypted with key created by /dev/urandom (in case that $target_keyfile does not exist) should be advertised to user as well...
There was a problem hiding this comment.
Disks are encrypted via a different key: This master encryption key still remains at high quality if LUKS_CRYPTSETUP_OPTIONS is used in its default configuration (--use-random).
/dev/urandom is used here to generate what's basically a very long (2k) temporary password, which remains valid only until the original keyfile will be restored and re-assigned. If this doesn't succeed, the "temporary password" becomes permanent and the following message is issued:
LogPrintError "$original_keyfile was not restored - LUKS device $device has been assigned a new keyfile"
I would hope that this gives the user a sufficient warning for this improbable case, possibly resulting from a non-functional crypttab configuration anyway. Would you say even more advice is needed?
| Log "Re-assigning keyfile $original_keyfile to LUKS device $device" | ||
|
|
||
| # The scheme for generating a temporary keyfile path must be the same here and in the 'layout/prepare' stage. | ||
| temp_keyfile="${TMPDIR:-/tmp}/LUKS-keyfile-$(basename $original_keyfile)" |
There was a problem hiding this comment.
What if I've used following keys for encryption:
/secure_dir1/key1
/secure_dir2/key1
Maybe I've misunderstood something, but wouldn't this mean that disks encryption will be done by same key, when in reality we've used two keys?
There was a problem hiding this comment.
Yes. Good catch. Will have to correct this. I happen to use a configuration where key files are kept in the same directoriy.
Isn't that the original system administrator's decision that we just recreate during recovery? He has finally decided to go with crypttab keyfiles after all. Do you think that this decision should be overruled by ReaR?
You are right. I'll correct this. Can you point me to the manpage you've used? It seems to be a rather old version of the cryptsetup suite as newer versions (like this one) don't seem to allow verbatim passwords there anymore. |
Like I said, for me this is politics, I don't like politics. ReaR is my spare time project and I don't do thing I don't like in my spare time.
I don't think so. Excerpt from http://manpages.ubuntu.com/manpages/xenial/en/man5/crypttab.5.html:
But to answer your question I've used |
|
OK, I misunderstood this one:
It initially sounded to me like is was meant to be a verbatim password first, and a path to a keyfile only under certain circumstances. When reading more carefully, it was never really meant to be a password. So they have just improved the explanation in newer incarnations of that manual page. Anyway, I'll take care of the special cases of 'none' and '-'. |
|
A "caution!" regarding running any programs in ReaR In ReaR interactive user dialogs won't work by default because |
|
@gozora Should work now:
|
|
@jsmeix UserInput works as advertised... ...but passwords then appeared in So I've reverted this change. |
|
@OliverO2 isn't that in debug mode? Then I would expect the passwords to show up. Users are not expected to use ReaR in debug mode so that regular usage would be save. |
|
@schlomo Invocation was just Seems like it's in Log output looks like this: |
|
Maybe the code around diskrestore actually enables |
|
Apparently, it's |
|
@OliverO2 thanks for updating this PR. V. |
|
Only a side note how to run commands really silently: # If confidential user input is needed also in debugscripts mode the caller of the UserInput function
# must call it in an appropriate (temporary) environment e.g. with STDERR redirected to /dev/null like:
# { password="$( UserInput -I PASSWORD -C -r -s -p 'Enter the pasword' )" ; } 2>/dev/null
I.e. you need to put confidentially working commands into { root_password="$( grep '^root:' /etc/shadow | cut -d ':' -f2 )" ; } 2>/dev/null
{ echo "$root_password" ; } 1>/dev/null 2>/dev/null
You cannot rely on that 'set -x' is not somehow set. |
|
@OliverO2 thanks for this improvement! |
Problem
ReaR 2.2 with cryptsetup 1.6.6 (as on Ubuntu 16.04.3 LTS) uses compiled-in default values which are not up-to-date in terms of cryptographic security:
For details, see Encryption options for LUKS mode in the ArchWiki.
In addition, ReaR can neither auto-detect nor use existing keyfiles for the automatic decryption of recreated LUKS volumes. A recovered system will ask the user for a passphrase where the original system would not.
Solution
This PR improves LUKS recovery with these characteristics:
--key-sizeoption from the original volume.Strategy
See comment in commit c9e7e1b.
Note: Removing the documented
modeoption is an incompatible change, which simplifies the code by processing each option in the same way. Sincedisklayout.confis usually re-generated before being edited, introducing this change seems OK to me.Tested on Ubuntu 16.04.3 LTS.