Hello! I don’t know if this kind of discussion has been initiated on forum before or anywhere else. Me and Perk1ns often discuss and share about our experiments for portable linux OS on different USBs. I am using Fedora with LXQt Desktop Environment on 16 GB USB for my personal space. I have my accounts, passwords, emails on it. My primary OS on laptop is Windows as I still need it. So have anyone else ever experimented with different OS on same Machine but on different SSDs? like for gaming - SSD with Windows, personal space - SSD with linux, for work (or career related) - SSD with Windows or Linux. What kind of possible downsides of doing this (except speed i guess)? How good this kind of setup is for privacy? How good (or bad) is it for security?
It’s great for privacy, it’s a bit more iffy for security.
The more you switch your OS and software, the more unique your fingerprint is going to be.
Malware could easily mount other drives, with FDE and secure boot this might not be a problem, booting one compromised OS could compromise all other OS’s one drives attached to the system.
My system uses secure boot. And as i can observe with fedora on USB, the Hard drive are by-default not mounted and requires admin’s permission on fedora to mount them.
You should assume that any malware is able to escalate to root privileges.
Unless you are encrypting all drives, you end up in a situation where the chain isn’t stronger than the weakest link, the least secure OS can compromise the most secure OS.
If you are using separate drives and you are also using full-disk encryption then it should be reasonably secure. The important thing is to make sure that one OS does not have access to the data storage of the other.
Hot topic for me. I have a Dell 3240, I think, which I have mentioned here on the forum, that has AntixLinux installed on its 8 Gb hard drive. This was the smallest PC I had that is x86 which allows me to run TailsOS. I also built up a Fedora thumb drive, Kali and MX Linux on USB.
I am learning more about Flatpacks and AppImages, which I am trying to treat like they are portable apps which I use on Windows systems. I want to check out Fedora SilverBlue.
I just mentioned in chat what is our malware concerns on fileless malware. As I understand the malware is stored in memory.
Alright. but even tho the disk is encrypted, the boot partition will be unencrypted right? Does it create any issues? I haven’t performed manually whole disk encryption with any OS installed, I usually enable disk encryption while installing Linux distros, so I am not sure if this is same for every case.
Yessir, you need to use Secure Boot with custom keys, and sign the boot partition yourself with those keys to avoid boot partition malware.
Something else you could do is install your boot partition to a USB drive, keep that drive with you at all times, and disconnect it when the system’s running. Nothing to infect if the bootloader isn’t stored locally in the first place, and you avoid evil maid attacks without using secure boot.
In this case, your system’s package manager won’t be able to update your bootloader automatically though, so there’s a risk of missing out on security updates. Always tradeoffs 
Yes, that is correct. And as already mentioned this is what secure boot is for. It didn’t always used to be the case, but fortunately these days most popular Linux distros should already have secure boot support.
I would like to preface this by saying these are risks most people will probably not realistically face.
For additional clarification, the problem with most Linux distros’ default secure boot support is that they don’t validate every boot component. A simplified boot process for most major distros looks something like:
- EFI firmware
- shim package
- bootloader
- kernel
- initramfs/microcode
- init system
- user space apps
Every step in this chain has to validate the next somehow. 6 → 7 is enforced with disk encryption, 1 → 2 is enforced with Microsoft’s certificate, 2 → 3 is enforced by the distro’s certificate pre-installed in the shim binary, but the rest gets pretty messy.
Click to expand: speaking of 1 → 2...
The other benefit to using custom keys is that you can replace the reliance on Microsoft’s certificate, by installing your custom key directly in your UEFI, negating the need for a Microsoft-signed shim binary. Microsoft signs many different objects with the same key, so it’s not impossible to imagine them signing something with bugs or backdoors at some point. If your UEFI doesn’t support custom keys, you’re stuck with enrolling your custom keys inside the Microsoft-signed shim, which still allows you to protect everything else I described above, but Microsoft signing something improperly remains a risk.
Typically the bootloader will verify the kernel image is correct (so 3 → 4 should be protected*), but the kernel’s EFI stub can only load an external initramfs image, and it has no code signature checks in place to prevent that external initramfs from being modified. Basically this means that there aren’t really proper verification steps going on during 4 → 5 → 6.
*grub is a little problematic here too, systemd-boot is probably preferable.
There are fixes for this, the usual fix is to create a unified kernel image which basically combines the kernel, initramfs, and microcode into one single package which can be signed for secure boot purposes. You can do this with your own keys, which is what I was alluding to when I was talking about using custom keys, but no major distros do this themselves to my knowledge.
Fedora is/was working on shipping their own unified kernel image instead of generating initrd images during the install, but it’s a long ways off from being the default, and you can probably only opt-in if your Fedora install is in a virtual machine or on very modern hardware: This is the reason distros aren’t yet shipping a unified kernel image themselves, because different hosts need different drivers during the boot process, which isn’t super compatible with the idea of sending the same unified image to everybody. Of course if you create your own unified kernel image with your own keys, you can create an image tailored to your host specifically, avoiding this problem.
All this being said, evil maid attacks being limited to initrd is still Better Than Nothing™, it limits attacks to the user space as opposed to the kernel itself, which should at least make them far easier to detect.
Really great post. I wasn’t even aware of half of all that.
Thanks @Jonah, this is the reply i was expecting when I was writing this post. This is a bit beyond my knowledge right now, but i will slowly digging into what you suggested and will give them a try.
For anyone who stumbles upon this post in the future, there is a current conversation on Privacy Guides forum that is a continuation of of the discussion on secure boot. If you are interested in secure boot, it may be of value to you to read that post also.