[SOLVED] FULL disk encryption on Slackware - avoid having to type password twice
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
FULL disk encryption on Slackware - avoid having to type password twice
Hello there.
Recently I decided to hop on to Slackware after becoming bored with Arch which I've been running on various machines for years.
At least for my laptop I always set it up using full disk encryption, which works flawlessly on Arch which uses mkinitcpio. FULL Encryption meaning that there isn't an unencrypted boot partition holding the initramfs, but a single encrypted root partition in the case of MBR - and aditionally an ESP for EFI.
The system can normally load the Grub bootloader, prompting for a password, which then decrypts the drive and loads the initramfs, which can then mount the root filesystem **inside** the initramfs, loading a keyfile from the decrypted root filesystem and decrypt automatically, thus avoiding making me type the password twice.
This works flawlessly on my other laptop running Arch.
This is how I have set it up: Grub:
Unfortunately Slackware is using the deprecated initrd tool which doesn't seem to provide this option. As far as I'm concerned it can only load a keyfile from a fat32 formatted thumbdrive. https://docs.slackware.com/slackbook:booting http://polarhome.com/service/man/?qf...Slackware&sf=5
But I don't want to rule out the possibility that I have made an error configuring the initrd file.
This is how I've set it up: /etc/initrd.conf:
Code:
LVM="0"
ROOTFS="btrfs"
ROOTDEV="UUID=xxxxx(root)(von blockdevice z.B. sda1)"
LUKSDEV="UUID=xxxxx(von blockdevice z.B. sda1):UUID=xxxxx(swap)(von blockdevice z.B. sda2)"
LUKSKEY="LABEL=THINKROOT:/crypto_keyfile.bin"
RESUMEDEV="UUID=(swap)(von blockdevice z.B. sda1)"
TL;DR
Is installing mkinitcpio on Slackware a viable option? Any ideas?
Hi,
with the same goal I had modified the script mkinitrd in Slint-14.2.1 using this patch. I have suggested to do something similar in Slackware, to no avail.
In Slint64-15.0 I have switched to dracut that handle that without any modification, further dracut knows which kernel modules include in the initramfs in this case, lot less maintenance for me as Slint maintainer. If I remember well I have also suggested to do that in Slackware, still to no avail. I also have suggested to replace lilo and elilo by grub several times, still to no avail. In Slint users are proposed at time of installation to have the target drive fully encrypted and then will have type the passphrase only once (when requested by GRUB). You may request to have this implemented in Slackware. Good luck.
PS. To be honest a solution is proposed for Slackware in README_CRYPT.TXT but I prefer not to add a level of complexity relying on LVM.
Last edited by Didier Spaier; 04-14-2023 at 11:18 AM.
Reason: PS added.
Hi,
with the same goal I had modified the script mkinitrd in Slint-14.2.1 using this patch. I have suggested to do something similar in Slackware, to no avail.
In Slint64-15.0 I have switched to dracut that handle that without any modification, further dracut knows which kernel modules include in the initramfs in this case, lot less maintenance for me as Slint maintainer. If I remember well I have also suggested to do that in Slackware, still to no avail. I also have suggested to replace lilo and elilo by grub several times, still to no avail. In Slint users are proposed at time of installation to have the target drive fully encrypted and then will have type the passphrase only once (when requested by GRUB). You may request to have this implemented in Slackware. Good luck.
PS. To be honest a solution is proposed for Slackware in README_CRYPT.TXT but I prefer not to add a level of complexity relying on LVM.
Man, you advertise so insistent that Dracut thing that I have started to think that you own shares of Dracut, Inc.
I for one, honestly I will prefer the Arch way to handle the initrds over Dracut.
And probably this mkinitcpio package of Arch Linux can be adapted to Slackware.
Last edited by LuckyCyborg; 04-14-2023 at 11:33 AM.
Unfortunate your patch didn't get accepted. Where eid you submit it?
There isn't a Dracut Slackbuild unfortunately. But it's easy enough to create our own packages on slack, as I've learned.
Can Dracut also resume from an encrypted swap?
Otherwise I'd prefer to use the tool that has worked for me before:
Quote:
LuckyCyborg
Will I have to make any modifications or will mkinitcpio work out of the box? I mean it's made specifically for Arch.
As for initrd being deprecated, I think it's functionality is deprecated, compared to the tools of other distibutions. But I guess that is something we have to live with on SLACKware. Other than that, from what I've seen I like Slackware a lot.
I followed the 'tumfatig' guide for FDE (apologies for not posting the link, but this is my first post and apparently one cannot post URLs in a first post => if you google 'tumfatig slackware fde' and use the article from 2023-01-31, you'll find it)
But on to business:
From what I can gather, you would consider this to be 'not full disk encryption' because the initrd and kernel reside on a non-encrypted partition.
Can you tell me what avenues of attack I should consider that would put my data at risk when doing it this way? I believe it to be sufficient based on the fact that nothing 'personally identifiable' is unencrypted. Should the laptop be stolen, all they'd have is a generic kernel and an initrd that points to an encrypted partition, which is likely already identifiable with an entropy map even without looking at the initrd or kernel.
Thanks for providing the package! I'll definetely try that tomorrow.
No offense, but I think most people nowadays will opt for more established projects. There are already so many Slack based distros. Maybe you should try getting your changes implemented into PClinux OS or similar who are using Slackware as base if Volkerdingen doesn't want to implement it.
Hi,
Can you tell me what avenues of attack I should consider that would put my data at risk when doing it this way? I believe it to be sufficient based on the fact that nothing 'personally identifiable' is unencrypted. Should the laptop be stolen, all they'd have is a generic kernel and an initrd that points to an encrypted partition, which is likely already identifiable with an entropy map even without looking at the initrd or kernel.
sstm
Well, one could insert a keylogger in your initramfs for example. Though, I admit, very unlikely if you aren't a target of intelligence agencies. If your laptop is simply stolen, a non encrypted boot most likely won't pose a major risk.
I also don't know if something similar could be done with UEFI? Couldn't you install malicious software in the ESP partition as well?
Maybe I just do it for the hell of it. Linux is an obsession after all. A good obsession, I like to think. You learn to use computers responsibly.
If I can't get it to work, I'll just go with the recommended layout of having a non encrypted boot.
Not sure if this will help but here is an article that has a way. I also get annoyed having to type my password twice on my laptop but have gotten used to it. I may try this in a virtual machine.
Well, one could insert a keylogger in your initramfs for example. Though, I admit, very unlikely if you aren't a target of intelligence agencies. If your laptop is simply stolen, a non encrypted boot most likely won't pose a major risk.
I also don't know if something similar could be done with UEFI? Couldn't you install malicious software in the ESP partition as well?
Maybe I just do it for the hell of it. Linux is an obsession after all. A good obsession, I like to think. You learn to use computers responsibly.
If I can't get it to work, I'll just go with the recommended layout of having a non encrypted boot.
Yeah, I'm using it with UEFI - the bootx64.efi is basically also just a little kernel that acts like an initrd would. The security comes from it being validated by the bios (or whatever inits this) before being loaded. I keep the vmlinuz and initrd.gz file in the same directory on the EFI partition and I'm using the bootx64.efi from slackware live. This .efi runs a minimal grub that scans all available volumes for a file named 'SLACKWARELIVE' and sets the grub 'prefix' variable to that directory. In your own grub.cfg you can then use that prefix variable to point to the vmlinuz and initrd residing on the partition with that file - this being the EFI partition.
You can use grub-mkimage to roll your own efi image - you can give it a grub.cfg file that does something similar or even does the cryptsetup stuff all immediately - I've read somewhere that this could entail a speed hit when loading because "not all resources are available to do this yet" - didn't verify this.
I believe that if you enable secure boot, it'll verify the image against your own keys (if you configure it to do so), but I think that ultimately this doesn't add more security because secureboot can be turned off (or a bios can be reset). Maybe the security comes from the keys being wiped if you reset the bios to reset the bios password (this would let you change what the valid signing keys are)? In any case, even without having secure boot active, if you manage to install a keylogger on my device using efi image or by modifying my vmlinuz or initrd, I'd say you've earned the right to see what games I'm playing and what my bills look like Anything with real worth can be covered with 2FA-related measures and I think that at some point, before running into every possible hurdle I can throw in there in order for someone else to access my data, the more "analog" ways of pressure will be applied to get me to yield that disk password.
It's a lot of complexity (which can be misconfigured, leading to even easier compromise) for something that they can ultimately get at anyways if given enough time and means If they really want your data and it's "this well guarded" (or if it seems that way), I'm sure that the more 'analog' ways of getting you to yield the disk encryption keys will be much more viable for any attacker.
No, you are right. If there's already forensic experts with that expertise at work, they might as well put us on drugs or torture us to get that password. And yeah, I even though I guess I'm pretty "edgy", I don't think I'm that interesting.
Will I have to make any modifications or will mkinitcpio work out of the box? I mean it's made specifically for Arch.
I do not believe that the Arch's mkinitcpio will work out of box on Slackware, exactly for the reason you already said.
BUT, in the end, it's also based in BusyBox & Co., then "someone interested" may succeed to adapt it to work properly in Slackware.
So, considering your previous experience with Arch, how about to take this porting of mkinitcpio to Slackware as your pet project?
In the end, from what I seen, Slackware is a county town where if you want meat at dinner, you should grab your dagger and go to forest, to hunt a bear or something.
Quote:
Originally Posted by dosensuppe
As for initrd being deprecated, I think it's functionality is deprecated, compared to the tools of other distibutions.
You may want to use the word "obsolete", because the deprecation is a decision made by someone.
In other hand, seems like our BDFL believes that his initrds cover all user cases. That they are perfect. I for one, I talked since long time about the necessity to make the initrds more modular. However, seems like to deaf ears.
So, feel free to argue (preferably showing patches or source code) about this subject, if you are interested on those things.
In the end, I can't argue alone with this entire forum for every little thing which I believe it's an improvement.
Quote:
Originally Posted by dosensuppe
But I guess that is something we have to live with on SLACKware. Other than that, from what I've seen I like Slackware a lot.
I believe that is unreasonable to expect the commodities from New York after you moved in a little county town surrounded by forests.
Last edited by LuckyCyborg; 04-15-2023 at 02:45 AM.
No, you are right. If there's already forensic experts with that expertise at work, they might as well put us on drugs or torture us to get that password. And yeah, I even though I guess I'm pretty "edgy", I don't think I'm that interesting.
You known, there's an old joke:
Q: Why according with the KGB specialists there is no password with a strength greater than 9 fingers?
A: Because anyone needs at least one finger to take care of his own nose.
Last edited by LuckyCyborg; 04-15-2023 at 02:12 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Anything with real worth can be covered with 2FA-related measures and I think that at some point, before running into every possible hurdle I can throw in there in order for someone else to access my data, the more "analog" ways of pressure will be applied to get me to yield that disk password.
If they really want your data and it's "this well guarded" (or if it seems that way), I'm sure that the more 'analog' ways of getting you to yield the disk encryption keys will be much more viable for any attacker.
