Error decrypting LUKS partition prior to capture/imaging

[Sebastian Roth]

@humoss233 said in Error decrypting LUKS partition prior to capture/imaging:

I run 1.5.5 because that’s the latest available as a docker container (https://github.com/Mudislander/fogproject).

Do you know the person creating this? Would be interesting to know why 1.5.5 was used and not updated since.

[Tom Elliott]

@Sebastian-Roth Too add on, 1.2.0 container to 1.5.7 container should still work too. The version the docker has may have 1.5.5, but I’m 99% sure that you can still upgrade it to 1.5.7.

[humoss233]

@george1421 mostly figured out the script, but having trouble getting it to run. I’m following your guide here (https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins/) but getting this error:

/images/dev/fog.postinit:

#!/bin/bash

. $postinitpath/fog.ACME.selector

/images/dev/fog.ACME.selector contains the script from your post and exeutes the decryption script if the machine type matches

Here’s the actual decryption script in a separate file:

#!/bin/bash

# only needed if using intel raid:
mdadm /dev/md126

pass_dec=`echo $pass_enc | openssl enc -base64 -d -aes-256-cbc -nosalt -pbkdf2 -pass pass:LOCALKEY`

for i in {/dev/sd*,/dev/nvme*,/dev/md*}; do
    echo -n $pass_dec | cryptsetup luksOpen $i $(basename $i)_crypt  -d -
    if [ -e /dev/mapper/$(basename $i)_crypt ]; then
        rm $i
        ln -s /dev/mapper/$(basename $i)_crypt $i
    fi
done

sed -i 's/blockdev --rereadpt/partprobe/g' /usr/share/fog/lib/funcs.sh

One would generate the encrypted key using echo 'MY_DECRYPTED_PASS' | openssl enc -base64 -e -aes-256-cbc -nosalt -pbkdf2 -pass pass:LOCALKEY and pass this in the “pass_enc” kernel parameter

@Sebastian-Roth don’t know the docker creator but his github is https://github.com/Mudislander/fogproject

[Sebastian Roth]

@humoss233 The error in the picture you posted is most likely due to the file being created on Windows using \r\n line endings. Convert the file to Linux file endings \r and it shouldn’t throw that error again.

Plus I see a difference in the paths: /imagesinit/... vs /images/...

[humoss233]

@Sebastian-Roth thanks! changing the line endings fixed the error and the difference in paths doesn’t seem to be an issue

I had to repad the base64 string as trailing ='s can’t be passed in the kernel parameter (they are ignored). Here’s the final result:

#!/bin/bash

# REF: https://gist.github.com/catwell/3046205
function repad {
  _l=$((${#1} % 4))
  if [ $_l -eq 2 ]; then _s="$1"'=='
  elif [ $_l -eq 3 ]; then _s="$1"'='
  else _s="$1" ; fi
  echo -n $_s
}

pass_dec=`echo -n $(repad $pass) | base64 -d | openssl enc -d -aes-128-ecb -K 691CACE3402341778F3DBCFD74859E0C -nosalt`

for i in {/dev/sd*,/dev/nvme*,/dev/md*}; do
    echo -n $pass_dec | cryptsetup luksOpen $i $(basename $i)_crypt  -d - 2> /dev/null
    if [ -e /dev/mapper/$(basename $i)_crypt ]; then
        rm $i
        ln -s /dev/mapper/$(basename $i)_crypt $i
        echo Decrypted $i
    fi
done
sed -i 's/blockdev --rereadpt/partprobe/g' /usr/share/fog/lib/funcs.sh

Generate the encrypted pass using echo -n 'MY_LUKS_PASSWORD' | openssl enc -base64 -aes-128-ecb -K 691CACE3402341778F3DBCFD74859E0C -nosalt and pass the result into a pass kernel parameter

Thanks again @george1421 and @Sebastian-Roth for all your help in making this work

[george1421]

@humoss233 First let me say well done!

I have just a few comments, the /r/n issue can be addressed if you want to develop your code on windows, use notepad++ its a much better cross platform text editor. Also if you develop code on windows with an application such as notepad, you can use a linux utility called dos2unix to strip out these extra characters with a single command line utility.

Your coding looks really good. You are doing several fairly advanced techniques. I’m going to post the diffs for both the kernel and the ints so that these changes don’t get lost with time. I may need to rebuild the kernel for another one off issue and your changes will be lost of I don’t get this added into this thread. I’ll do that early next week. That will also give you or someone else the ability to recreate what has been done.

[humoss233]

@george1421 sounds great re: adding - thanks again. I’m pretty new to linux shell scripting though I do a lot of Python work

[george1421]

Here are the patch files applied to both the kernel and inits to allow this type of encrypted file system.
crypto.kernel.patch-1.5.7.txt
openssl.init.patch-1.5.7.txt

[Sebastian Roth]

@george1421 Should we add this to the official FOG kernel/init? Do you know how much extra in size that is?

[george1421]

@Sebastian-Roth said in Error decrypting LUKS partition prior to capture/imaging:

Should we add this to the official FOG kernel/init?

(??)

I’m seeing this as still a one off situation. Until now I didn’t know LUKS partition encryption existed. I can say if we see more requests like this we can add it to FOS Linux. I added the patch files here so the changes don’t get lost with time.

From a size perspective the added openssl executable is minimal as well as adding in the crypto drivers into the kernel. Looking at buildroot images directory I see the uncompressed inits at 268435456 and compressed 19986704. I would have to recompile it without openssl to give you a (like for like) comparison. So the question from a developer standpoint is there any additional utility can FOG get from including the openssl executable? The openssl libraries are already included in FOS Linux for other reasons. Are we passing things between FOS and FOG today that should be protected a bit better in the future? Possibly in 1.6.x it would add some value (??)

[Sebastian Roth]

@george1421 said in Error decrypting LUKS partition prior to capture/imaging:

The openssl libraries are already included in FOS Linux for other reasons. Are we passing things between FOS and FOG today that should be protected a bit better in the future? Possibly in 1.6.x it would add some value (??)

We’ll do as soon as we see it’s needed.

[Quazz]

@george1421 I believe at one point it was suggested to use SSH to handle interactions with the server instead of ftp/nfs (one or both, don’t remember)

Though I imagine that’s further down the line.