Error decrypting LUKS partition prior to capture/imaging
-
@humoss233 Here are the inits that should have openssl application. For full disclosure I haven’t tested them myself yet, I ran out of time today. I’ll load it onto my usb stick in the morning USA time. But if you want to try to see if it works: https://drive.google.com/open?id=1OnVpqqGnFkVkS19B4OwNxP2FMoyustwT
You will just download them as initCrypt.xz and save it in /var/www/html/fog/service/ipxe directory. Then go into the host definition and add into the init field initCrypt.xz. As I said I don’t know if it will boot correctly (it should) but it also should have the openssl executable installed.
-
@george1421 getting error message below
-
@humoss233 It almost sounds like you are running an older version of FOG and your ram disk size is not 275000. What version of FOG are you using?
-
@george1421 I run 1.5.5 because that’s the latest available as a docker container (https://github.com/Mudislander/fogproject).
I changed KERNEL RAMDISK SIZE to 275000 and it now works - thanks! I successfully decrypted and encrypted a sample file using the following commands.
openssl aes-256-cbc -a -salt -pass pass:PASSWORD -in sample.txt -out sample.txt.enc
openssl aes-256-cbc -d -a -pass pass:PASSWORD -in sample.txt.enc -out sample.txt.new
Is the best way for the postinit script to access kernel parameters to parse
/proc/cmdline
? -
@humoss233 To access kernel parameters you can surely use the /proc/cmdline but also when the master FOG script starts to run it converts the kernel parameters into bash variables. So if you set a kernel parameter of foobar=XXXYTVBZ when the master FOG script starts it will create a variable called
$foobar
with the value set toXXXYTVBZ
.Version 1.5.5 may be close enough to 1.5.7 (init base I built against) so that there won’t be any problems. You might run into a problem because at 1.5.6 the name of the fog (linux) service account changed from
fog
tofogproject
. You might need to create a linux user on the FOG server calledfogproject
and set the password to the password found in the hidden file/opt/fog/.fogsettings
file. You will know there is an issue upon upload, once all of the files are uploaded you will see a ftp error and then another error about updating the database. But first things first, you need to get the password encrypted and then integrated into your code. -
@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.
-
@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.
-
@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
-
@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/...
-
@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 apass
kernel parameterThanks again @george1421 and @Sebastian-Roth for all your help in making this work
-
@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.
-
@george1421 sounds great re: adding - thanks again. I’m pretty new to linux shell scripting though I do a lot of Python work
-
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 -
@george1421 Should we add this to the official FOG kernel/init? Do you know how much extra in size that is?
-
@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 (??)
-
@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.
-
@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.
-