Error decrypting LUKS partition prior to capture/imaging

[george1421]

@humoss233 Well I guess a few things here.

1. The kernel parameters are not complete for some reason. There is a variable mode or something (like that) that should be up or down depending on if you are capturing or deploying.

so after running the cryptsetup, what does lsblk show? What happens if you manually try to mount that encrypted partition over /mnt can you read the partition contents?

Does this command cryptsetup luksOpen /dev/md126p3 crypt create a device called /dev/crypt?

If so /dev/crypt should represent an encrypted partition /dev/md126p3 and not the physical disk /dev/md126.

Understand we have not worked with encrypted partitions so we have to rely on your knowledge of the filesystem.

[humoss233]

@george1421 /dev/mapper/crypt is created, not /dev/crypt. Cryptsetup uses device mapper to create a mapped decrypted partition. I can mount this decrypted partition using mount /dev/mapper/crypt /mnt/temp and successfully view all the files on the partition. This is why I thought it’d work to use /dev/mapper/crypt in the “Host Primary Disk” field. Could FOS be confused because it expects to find a disk device and not a partition?

I’m not sure re: kernel parameters. This is a capture in debug mode. I’ve successfully completed captures of the full encrypted partition without debug mode (using /dev/md126 as “Host Primary Disk”). So, I’m not sure if missing parameters are contributing to the error.

See: https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Unlocking/Mapping_LUKS_partitions_with_the_device_mapper

See lsblk output below:

[Sebastian Roth]

@humoss233 Great to see George has come up with the correct set of kernel options for your crypto setup.

At this point I think we are hitting kind of a wall. We might find a hole through but I am not sure yet.

FOG is made to capture whole disks, so one of the first things it does is get a list of partitions from the device. This surely fails on /dev/mapper/crypto. There is an option in FOG that you can use to make it capture only one single partition (in the host’s settings you have Partition - defaults to Everything) but the script code as it exists right now would still try to enumerate the partitions and bail out.

So looking at your lsblk output my first idea was to set Host Primary Disk to /dev/md126 and create a symbolic link pointing from md126p3 to mapper/crypt. But that doesn’t work because /dev/md126p3 device file already exists. Hmmmm, well maybe you can delete it. It’s not an issue in the live FOS Linux because on reboot it will be restored. Try this:

mdadm -D /dev/md126
cryptsetup luksOpen /dev/md126p3 crypt
rm /dev/md126p3
ln -s /dev/mapper/crypt /dev/md126p3
fog

[Quazz]

It also looks like OP is using mdraid, not sure if specifying a disk will produce the desired results under those circumstances anyway. Though; I don’t know at all how that’s handled behind the screens so it could be no problem at all.

[humoss233]

@Sebastian-Roth clever hack! there was one more hurdle: blockdev --rereadpt in the runPartprobe function fails due to ioctl error on BLKRRPART: Device or resource busy because cryptsetup luksOpen appears to be locking the device. Luckily partprobe works fine, so I just replaced that part of the script. Here’s my final commands (the last line just shows that the line has been replaced successfully). After running fog, the decrypted partition/disk is successfully captured (with /dev/md126 as “Host Primary Disk”). 1 GB instead of 800 GB!

[george1421]

@humoss233 I’m not sure this will work, since you are linking the /dev/md126p3_crypt to /dev/md126p3 then deleted it and then recreating it as itself. You are kind of looping back to itself. I can see a circular link here.

I wonder if you can rename /dev/md126p3 right from the start to /dev/md126p3raw and then do your cryptsetup against the renamed raw device and linking.

[humoss233]

@george1421 That’s a good point and your method is safer, but the one that I’m using (from @Sebastian-Roth) also works - I unzipped and mounted the resulting .img file to make sure it’s good. It’s beyond me but cryptsetup must work in a way that once the decrypted partition is mapped, it’s no longer dependent on the device file representation.

Now I just need to think of a clever way of prompting for and transmitting the password over the network, as I’d rather not put the plaintext pass in the postinit script.

Both of you, thanks very much for your help!!

[george1421]

@humoss233 Hmm… pass-o-words…

How about an encrypted password passed as a kernel parameter to FOS Linux bzImage, then in your postinit script decode the password using local seed (same one used to encrypt the password).

[humoss233]

@george1421 that’s a good idea - I’ve been researching it, but it looks like openssl is not available in FOS. Is there another way available to decrypt a given cipher?

[george1421]

@humoss233 I don’t know off the top of my head of base64 is part of fos linux or not. But that would be one option

Update: Base64 is part of fos linux, but I don’t think that is the tool to use looking a bit deeper into it.

[george1421]

@humoss233 I’m rebuilding the inits with openssl included. This is only half of the issue if the kernel doesn’t have openssl enabled. We’ll see one step at a time.

Edit: Wait, I just remembered that we built a custom kernel for the LUKS bits, so I can add it if needed since you are already running a custom kernel.

[Tom Elliott]

@george1421 Open SSL is already built into the init’s, that’s how we can do SSH Sessions!

[george1421]

@Tom-Elliott Interesting the openssl application doesn’t seem to be in my usb boot. I think the ssl libraries have to be there for ssh. Let me search the inits. I may have just totally missed it when I checked.

[humoss233]

@george1421 thanks for looking into this!

By the way, here is a simple initial stab at a postinit script for folks using LUKS with FOG in the future. It tries to decrypt all partitions and then links the decrypted partitions in the cases of successful decryption. It currently uses a plaintext PASSWORD in the script, but hopefully we can switch this out for an encrypted password passed as a kernel parameter.

for i in {/dev/sd*,/dev/nvme*,/dev/md*}; do
    echo -n PASSWORD | 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

[george1421]

@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.

[humoss233]

@george1421 getting error message below

[george1421]

@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?

[humoss233]

@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?

[george1421]

@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 to XXXYTVBZ.

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 to fogproject. You might need to create a linux user on the FOG server called fogproject 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.

[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.