Need to bounce some encryption thoughts off some fellow Linux nerds and get some advice.
Posted by mrandr01d@reddit | linux | View on Reddit | 52 comments
Flagged as discussion because I'm hoping to have one haha. Admittedly, I might be a little bit more of a noob than a nerd... Anyways...
So I have a Thinkpad x9 that I bought with windows. I need dual boot. I installed Ubuntu 25.04 on it last year, and have since upgraded it through 25.10, and I'm now on 26.04.
Because I dual booted it, apparently, nothing was encrypted. I remember going back through the installer UI and picking luks, but I guess going back through the manual partitioning method on the version I used meant that nothing actually got encrypted.
So now I have a dual booted machine with no encryption whatsoever. Seems like newer Ubuntu versions do support using luks and dual boot.
So, what to do? It sounds like you cannot encrypt a partition while it is mounted, meaning that if I want to encrypt my Ubuntu partition, I would have to do a full clean install. That's a huge pain in the ass, but I do have a time shift back up that I could use to restore most stuff. And I guess it would be an exercise in making sure that that works like I think it does in case of future unplanned disaster.
However...
Full disc encryption (fde) really only protects you against threat models where your device is powered off. If it gets swiped from a coffee shop or confiscated by the cops (idk, maybe I have some spicy memes I'm taking through TSA that this admin doesn't like... kidding, but still) or something then the keys are still in ram, and a thief can just brute force your password to get past the UI.
I basically never turn off my laptop. I pretty much only reboot it when I have to for updates. I think this is very common behavior among people generally.
Android and iOS have changed their encryption methodology to use file-based encryption, where the device can boot the OS without the user putting in their password, and the user's data is protected with the screen lock. Clearly, since it can boot, the whole drive isn't uniquely encrypted, but if your phone gets stolen or something, your lock screen can still protect your data.
I was asking Gemini about Linux's approach to this, and it said the Linux approach has pretty much settled on full disk encryption instead of only encrypting your home directory, but that Ubuntu does still support encrypting just your home folder, and that it would be protected by the OS's lock screen.
So, here's my dilemma: why has Linux settled on fde instead of encrypting the home folder? It doesn't matter that much if certain OS files are recovered by an attacker, but it'd be pretty bad if your personal files were compromised. I'd really like to avoid having to reinstall my system if possible, and it seems like encrypting my home folder better matches my threat model of having my device swiped in public while powered on, but locked. On the other hand, this doesn't seem to be the recommended way to go, and I would also be worried about support for just encrypting /home being removed in the future.
What does r/Linux think?
Razathorn@reddit
I'm an expert in this area. I've been running luks encryption on devices since it was first available and in a past job we implemented an encrypted file area via a custom windows driver for a vpn product we made (waaaaay back in the xp days). You're somewhat oversimplifying the issue. LUKS is just a "device" wrapper. It can be used in quite a few ways. The way I use it is I have one physical volume encrypted and then I have lots of logical vols on it. Other people use lvm to make multiple encrypted volumes instead of just encrypting the entire physical volume. The most common setup you will see is individually encrypted / partition (not lvm) and perhaps the next most common is encrypted / with an /etc/crypttab file that contains the password for /home on another partition.
See, luks just turns an unencrypted block device into a encrypted block device and is unlocked via a boot time password (the way I do it at least). Yes, when the machine is running, the encryption key is in mem, but your os prevents access via the lock screen etc. It is vulnerable to rogue thunderbolt malicious device direct pci memory access, but you can disable that via bios or with some "hot plug" prevention things in linux that I don't recall off the top of my head.
Generally, I don't trust TPM and would rather use a boot time password all day, but I don't encrypt my /boot efi partition so I'm 100% vulnerable to somebody who has physical access and poisions that to capture my password. Also, they could use a usb key logger.
You need to ask yourself how much protection you want.
Glad to chat about it if you want. This is an area I've been deploying for many years.
mrandr01d@reddit (OP)
Do you understand Android's encryption paradigm and methodology enough to discuss that in comparison to Linux? I'm very interested in why they switched to fbe instead of fde... There was definitely a QoL/ease of use aspect since users were having problems with their phone rebooting in the night for an update and then missing alarms, etc since it couldn't decrypt without the password, but I remember reading an article explaining the threat model too. iOS has always used fbe, and the article was basically saying that's better. It still provides some protection when your screen is locked, even after the device has booted.
Razathorn@reddit
I do not know about android's at all.
mrandr01d@reddit (OP)
Damn, bummer. Thanks for everything you've written! I think I'm probably going to have to end up reinstalling. I initially installed 25.04 on this machine last year, and 25.10 added support for like and dual boot in the GUI installer. My buddy installed that and his is encrypted the right way. Turns out I also made a swap partition I don't actually need, so it'll be nice to get the 30 or so gigs back anyways. Any tips on getting everything back up exactly how I have it asap? I have an external drive I'm currently using for timeshift. A couple things I've read so far:
After the reinstall is up and running, import a previously exported list of all my packages. I guess there's some command to make apt install the exact same packages that were on it before, and remove any new packages that weren't present on the old one.
Copy over your home folder
Selectively copy things in /etc in like your hosts file or your apt configuration file
Copy everything related to flatpak - is this just a directory somewhere under /var?
Somehow restore gnome extensions and their settings?
Not sure what else I'm missing...
Razathorn@reddit
You should always have a swap partition. That's the laptop person it me saying that. The reason is two fold: 1) if you have a laptop, you can do hybrid sleep and setup resume from hibernation. Second, anything like large shared objects like .so files etc or ram you are not using currently will eventually find their way into swap. It makes the system faster. A third point--with swap, a run away program will cause the system to chug a little and you can notice things are getting close to the edge while using it if you run out of physical ram. Without swap, programs just exit when with no warning because the kernel oom killer slays your big processes.
I honestly you don't need to re-install. You just need to convert your existing system. Having said that, it is probably WAY more complicated if you're not accustom to doing legit low level system building and restoration, like setting up the boot loader fresh, setting the kernel params to find the root disk, setting up the initrd to enable crypt, etc. It is not straight forward, I'm trying to not sugar coat it. this is something I do a lot on arch and arch arm, but I don't know the "ubuntu way" anymore. I've since moved on to systemd-boot and systemd-initrd and arch doesn't wrap stuff in scripts / helpers and "commercialize" the experience so I'm afraid my very direct way of doing something would end up being more harm than good.
mrandr01d@reddit (OP)
I read that the modern away of doing it is the system just has like a swap file of sorts on the same partition instead of a completely separate partition? My buddy I mentioned doesn't have a swap partition and his behaves just like mine does, so I don't think mine is even using the swap partition.
Reading another comment here, it seems very possible to just make another luks partition on my empty disk space, copy everything (but not everything?) over, and then resize the luks partition to "eat" the current / partition. This would be preferable, but I think it might be a little over my head. My career is in healthcare, this tech stuff is just a hobby for me, so I've never gotten too low level with things. (If I did I'd probably make more money...)
mrandr01d@reddit (OP)
I want to make sure nobody can dirty maid my os files, and that if the laptop is stolen while in a public place, powered on but screen locked, that I have the best defense against someone getting at my personal files. What do you think?
Razathorn@reddit
Then that's the whole shebam. You need secure boot setup as well, and then you will want to mitigate dma attacks via thunderbolt. Google those topics and you will see the high level.
mrandr01d@reddit (OP)
Would it be possible to make another partition on empty disk space, encrypt it, copy everything to it including the os, then resize it to "eat" my current partition? If I have to reinstall, I want to make sure everything is exactly the same after. I've done several customizations including the hosts file, gnome extensions, eliminated snaps, added flatpak...
Razathorn@reddit
What you're describing normally is done via lvms. Doing it via partitions unfortunately needs the starting place on disk to be fixed. You could shrink your main partition down, add another partition, copy the data there, then convert your new partition to a luks partition, copy the data back, then blow away the temp partition and expand the root one AND the luks AND the filesystem again. That would be my approach, or I'd just tar it to another system over the network. Regardless, you will be doing this on a usb stand-alone system boot for a while.
dack42@reddit
You could use secure boot to mitigate that type of attack.
Razathorn@reddit
Aware. I just don't care enough, yet. I just recently started using systemd-boot so I might check it out one day.
michaelpaoli@reddit
Nope, that's not why.
Not all that hard. You probably messed up in setting it up manually and didn't get what you intended regarding encryption. Not that hard to set up encryption, even with dual boot. And yes, even using manual for setting up the partitioning.
Yes ... and no. Can't change underlying device, e.g. partition, from not encrypted, to (LUKS) encrypted while it's in use. Might be alternative ways to do encryption, but let's not further complicate things on that, and stick with LUKS for drive/partition/device encryption, and particularly since that's apparently what you originally intended. So, if you've got your *buntu (or more generally Linux) stuff relatively well spread out and broken apart - multiple filesystems, partitions, maybe also md and/or LVM, then it's generally easier. If you just threw it all in one large partition (or almost everything), then it's significantly harder. In any case, to go from not encrypted, to encrypted with LUKS, you need to some shuffling around. And if you aren't using md and/or LVM and/or don't have spare space, that makes it a fair bit harder - far from impossible, but harder. Of course one could opt for a full clean install, but that may or may not be easier, e.g. depending what data one would want/need to save/migrate, etc., configurations to save and restore or merge back in, etc.
Backups always good, 'cause sh*t can fail. E.g. any drive can die, at any time, with or without any warning. And of course, humans, software, bugs, accidents, hardware, sh*t can happen, and the general enforcement of Murphy's Law tends to ensure it does.
Not entirely so, but that also depends on hardware and other factors. And there may be other more efficient methods ... rubber hoses, tanks, ... but let's not get lost in the weeds - that's be whole 'nother discussion. So, back to encryption with LUKS ...
Am I gonna have to fire up a weed whacker?
It's not (that) "settled". Don't believe the hallucinations of an AI, or one that may be trippin' balls.
You can encrypt and/or not encrypt, more or less whatever one wants on Linux. And sure, probably most distros, if one picks the simplest available encryption option at install time, are an approximation of full "disk" (drive) encryption - but almost none of them default to really entirely LUKS (or otherwise) encrypting the entire drive. Sure, most of it, but whole thing ... no. Doing MBR or EFI boot off that drive? Yeah, that and partition table isn't encrypted, and with EFI, the EFI partition isn't encrypted. With MBR, the MBR itself also isn't encrypted, and typically /boot wouldn't be encrypted, but there are potentially ways to install where even /boot is encrypted. Yeah, to have the entire literal drive encrypted with LUKS, you have to be using something else to boot, e.g. USB flash, (micro/mini)SD, etc., because if you do LUKS to the entire drive, there is no partition table (and yes, one can very much do that - but you won't be booting direct off that device).
Well, that's why I'd suggest, if one is rather/quite concerned about security and wants /home (or one's HOME) encrypted, that's not very full coverage - even for those files, notably for actual active use, etc. Would probably want to also cover at least swap, /var/tmp, and /tmp if it's not already tmpfs. And of course does also depend upon one's threat model too, so may want/need to encrypt more than "just" all those, to have relatively full(ish) protection of /home (or one's HOME).
Very doable. Not exactly trivial, but highly doable.
I think your questions are rather meandering ... not on LUKS, how to get to LUKS, encrypting (most) everything ... uhm, dual boot? Other encryption means, thread models, AI, other OSes, ...
Would be way easier if you said I'm in situation X, I want to get to situation Y, how can I do that, with or without reinstalling? But no, your questions are all over the place. Anyway, I addressed the ones that at least stayed approximately on (at least the starting) topic.
So, yeah, first thing to do to figure out how to get to where you want to be, is figure out where you want to be, and sounds like you've not even figured that out yet.
mrandr01d@reddit (OP)
How?
michaelpaoli@reddit
outline:
That's basically it. And yes, I've done conversions from non-LUKS to LUKS, without reinstalling - not all that hard. Sure, fair number of steps, but generally none of 'em all that horribly complex.
mrandr01d@reddit (OP)
So surely I can't just copy everything back to the new luks partition, right? Since there's stuff under /etc that has instructions for decrypting at boot? I read something that said if I just copy everything back my system won't be able to boot.
mina86ng@reddit
Start turning off your laptop.
If your laptop gets confiscated and judge says you have to unlock it, you have to unlock it. If not, it’s treated as not cooperating with a warrant or destroying evidence. And when you’re at the airport, just assume that you have no rights. If you have anything spicy on your device, get a fresh device and access anything spicy over VPN from your home.
It’s not. Not in any meaningful way. If someone grabs your powered-on device, regardless if you’re using full disk encryption or just encrypt your home directory, the data can be recovered.
Because it’s more secure.
Personal files like those that may end up in
/tmp? Furthermore, leaving system files unencrypted allows for evil maid to trivially install a root kit. This is a bit harder with full disk encryption. (To make it even harder you’d have to use drive’s hardware encryption which is unlocked by BIOS/UEFI).mmmboppe@reddit
this contradicts the presumption of innocence and your right to remain silent
mina86ng@reddit
It doesn’t contradict the presumption of innocence. If judge signs a warrant to search your house, you’re still presumed innocent, but judge ruled that there’s enough suspicion to search your house.
For right to remain silent see my edit.
mmmboppe@reddit
defective analogy
your password is inside your brain, not inside your house. a judge can't sign a warrant to search your brain
mina86ng@reddit
How do you think warrants work? If a judge signs a warrant to search your house, does that contradict the presumption of innocence or your right to remain silent? The same applies to warrant to unlock an encrypted device.
SomeRedTeapot@reddit
Are you sure every single country in the world has these?
mmmboppe@reddit
I am sure every educated person on this planet knows these basic principles, but if you're ok with benevolently giving them up, it's your problem
TalosMessenger01@reddit
It seems like it would be considered a fifth amendment violation if someone were coerced into giving up the password for an encrypted drive.
finbarrgalloway@reddit
Only true in the United States which has stricter search and seizure laws than most places. In most of the world you very much can be compelled to give up a password.
TalosMessenger01@reddit
It seems like it would be considered a fifth amendment violation if someone were coerced into giving up the password for an encrypted drive.
images_from_objects@reddit
DDR4 RAM holds memory for milliseconds when powered off.
Power your shit off.
mrandr01d@reddit (OP)
No. The whole point of a laptop is that it's running all the time and all my shit is always open and ready to go faster than I am.
images_from_objects@reddit
Totally fair. However, if you are concerned enough to want meaningful encryption on said laptop, FDE is the sensible option. Entirety your call.
orev@reddit
Yes, this is correct. The scenarios about getting the keys from RAM, or brute forcing the login screen are technically correct however the risk is very small. The attacker needs to be very sophisticated to do that, so it stops a lot of people who would more casual about it.
If the OS files are not encrypted, then the attacker could inject a compromised binary into the OS files, then put the laptop back. Eventually you open the laptop and run the binary, and that executes something to grant the attacker access.
TheOneTrueTrench@reddit
Also you can just configure PAM to lock the account for 5/10/30 minutes after 5/10/30 password failures, or whatever you want to configure it for.
Also, in terms of the OS files, in order to completely secure your laptop against someone with physical access secretly doing something, you need to setup secureboot with your own keys, and remove the MS ones, and set a UEFI password so that they can't inject something into the UEFI boot process.
mrandr01d@reddit (OP)
Android has verified boot and locked bootloaders to prevent the os being modified... If I set a secure boot password on my dual booted Linux/windows machine, what happens if someone messes with the os files?
NekkoDroid@reddit
A secure boot violation and the OS isn't launched
AmarildoJr@reddit
Unfortunately this is one of the areas where Linux is lacking support. On Windows you can encrypt your C:\ drive while it's mounted, using something like TrueCrypt/VeraCrypt (my personal favorite). Sadly VeraCrypt doesn't support encrypting your / drive while it's mounted, last I checked.
But there is one positive in all this, honestly, which is that you don't waste SSD writes. Doing a full re-install (while encrypting it) means only the newly written data is encrypted. On Windows, however, when you encrypt your C:\ drive, it literally re-writes every single sector encrypted, which wears down your SSD/NVMe.
Technically yest. If an attacker grabs your laptop while it's running, it's your OS that is protecting your account, so they need to try and reboot with a Linux USB to see if they can see your files, which they won't be able to.
Very unlikely attack scenario, probably not realistic in a real scenario, specially if you're not an EXTREMELY valuable target. And even so, it's improbable that you'd even encounter an attacker smart enough and available for such attack.
The problem with this approach is that it's not secure. An attacker can still compromise your /boot partition and Kernel and apply a Keylogger to get the password from you. I think it's called "The Evil Maid Attack". Moreover, files in /tmp and other such folders wouldn't be encrypted, so there is easy retrieval there.
In that case I would do it like you say, creating a new /home folder (encrypted) and moving my data there. But personally I don't like this approach, I also go for FDE as it is much more secure.
Well, it can happen, specially since we're talking about Ubuntu. But I personally don't think it will happen, at least not any time soon.
If unsure, do a full re-install and go for FDE.
ephemeralmiko@reddit
Isn't that more a LUKS vs Veracrypt default settings thing? If you do a secure erase and format with LUKS it also overwrites every sector, and Veracrypt can also only overwrite data, as opposed to encrypting every sector. The issue is that deleted data that was previously in plaintext and hasn't been overwritten could be retrieved with forensic analysis.
AmarildoJr@reddit
Kind of. Only some distros do a full "secure wipe" by default when installing them, on most distros you must actively click that option. So only the new data gets encrypted.
On VeraCrypt you don't have the option to skip encrypting every sector, it's mandatory. The only option you have is to either do a simple zero pass, or do one of the random pass options (military grade or whatever).
ephemeralmiko@reddit
For encrypting a system drive that's true, but when creating a standard VeraCrypt Partition (not a container) there is an option to do a Quick Format which doesn't overwrite anything.
AmarildoJr@reddit
Oh yeah! Absolutely. Completely forgot about that 😃
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
iamapizza@reddit
You have plenty of answers here and I think you kind of already knew, it's just the momentum of having to start over or change habits which is stopping you.
You could use the activity of reformatting with full disk encryption to ensure that you have backed up everything you need.
As for reboots, while it might be common for many people to not reboot, now that you know better, you could start changing this habit. I regularly shutdown at the end of the day, since the reboot is pretty fast anyway, there's little harm in waiting a few seconds.
Security and privacy won't come for free, it does involve evaluating and changing habits.
mrandr01d@reddit (OP)
I'll basically never routinely shut down my computer again. My pocket computer is always on and online, I expect the same of my laptop as well now. I don't want to close things I'm in the middle of working on unless I really have to for an update.
My old MacBook handled this well.
Barafu@reddit
Keep your private files in a virtual machine where a guest OS has full encryption. Much less conspicuous too.
phoenix823@reddit
Because encrypting everything is better than encrypting some things and potentially missing something. If one of your apps caches data somewhere outside of home, now you've got unencrypted data sitting there. Simple as that. And for what it's worth, FDE has been standard on Windows machines in corporate environments for more than a decade. This isn't Linux-specific. Your use case of only encrypting certain files is the outlier, not what the kernel/distro people did.
mrandr01d@reddit (OP)
Why are mobile oses no longer using fde? Android used to, but switched to file based encryption.
mmmboppe@reddit
get a second linux only fde laptop for carrying it to a coffee shop
TalosMessenger01@reddit
It seems like it would be considered a fifth amendment violation if someone were coerced into giving up the password for an encrypted drive.
edgmnt_net@reddit
It's kinda hard to secure these things properly (assuming software means) in a traditional POSIX environment because less or no provisions are made for suspending apps, for one thing. So just locking your screen on Linux still requires leaving programs running and keeping a live encryption key somewhere. Or you have to log out or suspend or whatever, but it takes longer to enter that state and recover from it.
Now I'm not sure how deep Android goes with this, but it does go deeper than Linux. And it's able to do that because the standard API and environment isn't POSIX or some Linux flavor of POSIX. Also, while Android can run some regular Linux apps, some adaptation work is generally required to achieve native-like integration even without considering purely GUI functionality. You can't just trivially port an IRC client because the user will experience frequent disconnections when the mobile OS decides it's time to park backgrounded apps. And a lot of the more traditional things running on Linux simply have not been designed with such an environment in mind (although it can be made to work for some related stuff, see CRIU for live migration).
ElvishJerricco@reddit
That's an oversimplification. A system that's powered on and has its encryption key in memory should be quite difficult to extract data from. It's not as simple as "a thief can just brute force your password to get past the UI" because brute forcing that should not be easy. Similarly, the system should be reasonably protected from network or USB attacks. Of course, the key is just sitting there in memory, so it's always going to be possible to use really sophisticated equipment to just read the contents of the system's memory. But that's a very difficult attack to pull off. So in theory, the running system (with the key loaded) is only ever softly defended against exfiltration, but in practice these attacks are at least supposed to be high difficulty, and not the kind of thing random laptop thieves are going to be capable of.
The primary (valid) reason is tampering. It's extremely easy to just modify the files on an unencrypted file system. Pop the drive out, plug it in somewhere else, run a quick program, and put it back. Or even just boot the system into a USB drive that writes a backdoor to the internal drive. It's a remarkably easy way to put a backdoor on the system, so the unsuspecting user just boots it back up and enters their password directly into a malicious OS. Now, this problem still exists even when the OS is encrypted, because you can't encrypt the whole OS; namely the boot loader must be unencrypted. And that's just as good an attack for adding a backdoor. In principle this is defended against by signing the boot loader for UEFI Secure Boot, but this is pretty meaningless in practice because most systems are relying on Microsoft's public keys for that secure boot, which basically lets them swap out the boot chain with a backdoor anyway.
iOS and Android can get away with not encrypting the OS because the whole boot chain is signed. You can't replace any component in the boot chain with a backdoor because all of it is protected by various forms of signature and encryption. You can implement this (or related mechanisms like "measured boot") with Linux, but it's not something basically any distro is doing out of the box right now. Ubuntu is probably the one that's closest with an experimental installation feature. Their "experimental hardware backed encryption" mode does full disk encryption, signs the boot loader, kernel, and initrd, and then encrypts the OS using the TPM2. That lets it boot up without a passphrase prompt, and the TPM2 makes sure the OS is basically as tamper-proof as a signed OS like iOS is (as long as you do it right and there's no TPM2 bugs, both of which are fraught (though Ubuntu does seem to have done it right)). But of course this still just leaves you in a state where this encryption has its key loaded at boot and it stays loaded, so if that's a concern you would still want to use separate encryption for your home directory.
ballsannihilator@reddit
You are correct about encrypting OS files being pointless, it doesn't actually protect anything because the initrd is not verified at all in most distros. FBE does have an issue with not encrypting metadata however.
Ok-Winner-6589@reddit
No? While installing Mint there is an option to encrypt the home partition (but you need to have one). Obviously, when unlocked, the whole home isn't encrypted. However you can lock specific files or folders by managing the permissions or using specific software.
With permissions you can make sure only root has access to the files (just limit the permissions from something to 000) this way the file isn't readable, writable or executable unless you have high privileges.
However this method is vulnerable to malware attacks. As someone can install malware to soy on your so, when you unlock It, the malware would be activarse and send the data they want. This only can be solved with encryption on the / partition
Another alternatives are using services like the secrets portal. So your Window manager/Desktop enviroment handles the access to specific data. Brave for example uses It for something (IDK what, probably crypto stuff).
XiuOtr@reddit
There are so many articles that explain the difference in each. What is your threat model?
MatchingTurret@reddit
I think this belongs into r/linuxquestions.