When one chooses an encrypted storage device in Anaconda, I don’t see why the OS doesn’t configure reboots to not require a passphrase. The security model of a reboot differs to a shutdown, due to the implicit expectation that the user intends to continue using the device.
2 Likes
Maybe there is no secure way to pass the luks keys across a reboot?
I am just guessing that all ways to pass the keys allows them to be intercepted by a adversary.
2 Likes
Perhaps doing so could be a bigger security issue.
What if the system were temporarily left running by the user and another forced the reboot.
I can see where the minor inconvenience of entering the password may greatly enhance security in several situations.
2 Likes
@barryascott, a few methods exist, as cited in the linked thread:
@computersavvy, I don’t see what the security consideration is there. All you’ve stated is that a user can reboot their device.
It’s more than that. A user needs to be able to temporarily lift a security restriction, and leaving a machine to reboot to install updates is encompassed by that.
Do you mean the use of a keyfile?
That does not sound secure at all. I would just interrupt the reboot and grab the keyfile.
@barryascott, if you were doing what?
From what I understand from the other post in the KDE forum, one option would be for the software manager (Discover in this case) to use systemctl soft-reboot when installing updates, in order to reboot userspace only, leaving the kernel running, but this doesn’t seem to be a valid option, since certain offline installations need rebooting with the kernel. The other solution suggested there was for the software manager to apply updates on shutdown, instead of startup, but here PackageKit has some limitations.
So a keyfile on a USB seems to remain an alternative solution, but I think this is not what you’re looking for, @rokejulianlockhart.
1 Like
I followed the link you posted and then war-gamed breaking the keyfile proposal.
FYI what I do in my home lab is use a tang key server.
I then use clevis to add an alternate unlock method to LUKS.
The key server keeps the unlock crypto materials in a LUKS encrypted partition.
With the tang key server up and running my LUKS partitions unlock automatically. Without the server being up I can enter the pass phrase to unlock.
2 Likes
@tqcharm, it’s acceptable if it’s the sole solution that exists, so thanks for summarising. To confirm, there’s no way to pre-authorise LUKS during reboot without having a keyfile available in a (separate), unencrypted storage device?
1 Like
That’s my understanding, because any pre-authorization would mean an unacceptable security compromise IMO.
EDIT: for an automated process, you could take a look at the solution mentioned above by @barryascott regarding Tang+Clevis, or those described in this Fedora Magazine article, or this one. Neither is an OOTB solution though.
2 Likes
@tqcharm, because software could add it to the local disk? If that were true, sudoers would be vulnerable. It’d merely need to be in a directory owned and controlled by the superuser. If you envisage something else, what is it?
They’re indeed of the same topic as this, but although I’ve read two articles, I don’t see any evidence that these are restricted to reboots.
This matters, because if they merely automatically decrypt the storage device at boot time, don’t they negate the entire point of having an encrypted storage device? I can only see that being useful if the user both wants the convenience of not having to enter their LUKS password, and frequently removes their machines’ internal storage devices. That’s niche.
On unencrypted storage, “owned and controlled by the superuser” is a concept that only applies within a running Linux system.
For example, I can boot into a live USB environment and read and write any file in an unencrypted partition from my on-disk install. (Like you might do to fix a broken /etc/fstab that prevents booting, for example.) To do that, I don’t need to supply a password to the root (or any other) account within the installed system.
The Tang+Clevis solution depends on your machine being able to access a server on the LAN that has the decryption credentials. So you don’t need to type in your LUKS passphrase when you’re on your home network, but you do when you’re in Starbucks.
For the TPM solution, you can set it up so that decryption only happens when you are booting into your unmodified Fedora install (because of the “PCR measurement” concept discussed in the article). So, if I purloin your laptop and try to boot into your Fedora install, I don’t need a LUKS password, but I can’t log in because I don’t have your account credentials. If I try to bypass that and read your drives by booting from a live USB, then the PCR measurements detect that I’m not doing a “normal” boot, and prevent the TPM from making the LUKS credentials available.
So either of these might or might not be appropriate depending on your threat model.
2 Likes
Given that currently a full reboot is necessary, I imagine that the LUKS passkey would need to be temporarily stored outside of the root partition (which is encrypted at that stage), hence the unacceptable security risk.
I’m thinking rather to the laptop use case. When the laptop is used within a trusted private network (e.g. home network), then the automatic unlocking is in place (e.g. with Tang), but when I leave that network, I would have to enter the passphrase.
My use case is that at home my devices are easy to use.
But if someone steals any of my hardware it is useless to them, they cannot unlock my disks.
There is a related usecase in data-centers where remote reboot just-works becuase of a key-server that is physically secured in the data-center. If servers are stolen the data on them is beyond thiefs reach.
3 Likes
@tqcharm, that’s not my threat model. My desktop literally can’t be stolen because it’s a 25U StarTech rack, so there’re no similarities between my laptop and desktop. Additionally, despite its construction, I’ve also no desire to run a key server on my LAN (alongside my desktop).
Lastly, what renders all of that moot is that my laptop might be connected to a cellular network, even at home, due to LAN congestion. I solely need it to be able to reboot without interaction, so a key on an external storage device appears to be my best option. It’s just a bit of a pain in comparison to a temporarily-stored internal keyfile, that’s deleted created before reboot, but deleted after reboot.
Considering that this is possible on Windows 11, it should be on Fedora 42:
#!/usr/bin/env pwsh
#Requires -PSEdition Core
If ($IsWindows) { Suspend-BitLocker -MountPoint "$Env:SystemDrive" -RebootCount [Int] }
For convenience, if you’d like to avoid using an external media for the key file, but nevertheless skip entering LUKS passphrase upon reboot specifically, I imagine the following setup (in case compromise acceptable):
- Create a keyfile and store it on the root partition;
- Update
/etc/crypttabto point to a keyfile located in a non-encrypted location (e.g. under/boot); - Create a bash alias (e.g. named
restart) which would: copy the keyfile from the root partition to the location defined incrypttab&& reboot the system; - Create a systemd startup service that would delete the keyfile if found in the location defined in
crypttab.
That way, anytime you’d run a restart, no LUKS passphrase would be required, since the keyfile had previously been temporarily copied to the defined crypttab path, as opposed to a regular boot, which would not find keyfile and require the passphrase instead.
This would limit the reboot action to the CLI though, and would not be of any help with Discover installing updates upon reboot.
2 Likes
@tqcharm, perhaps, it could be added to reboot.target, so that it’s always executed, even via the QDBus method that Discover appears to execute:
2 Likes
You want to allow only a single passwordless boot with a temporary key that is immediately destroyed and cannot be intercepted and copied by a third part with physical access to the machine. The only way I can see to do this securely, would be to leverage some specific function of UEFI boot or TPM, which must be in secure mode. I’m not even sure it is supported, but if Windows can do there is no other way.
I.e. it is similar to how the decryption key is stored in some TPM chip “enclave” to allow decryption with a fingerprint. The chip stores the key in a “safe” place and independently validates the biometric authentication.
1 Like
It doesn’t answer the question, but I just want to mention you can still use sudo dnf update to install updates without rebooting (e.g. before shutdown). For me, using both LUKS and dual boot, this is the only practical way. Beware though, that if you don’t shutdown or reboot after core package updates (libc, kernel, etc), the system could be in an inconsistent state, and this is why the added the reboot logic to begin with.
I used to do it with “dnf update” (or apt upgrade, etc) like that, but a couple of times I’ve had catastrophic failures: an update of KDE libraries causing the terminal in which the update was running to crash. If you want to do it this way, I would recommend switching to a terminal with ctrl-alt-f3, so that if the update causes any instability with the graphical session, it can still finish.