I used PopOS, but once they announced they’ll start focusing on their Cosmic desktop, I switched to Fedora KDE it worked to some degree until it crashed and I lost some data, now I’m on Ultramarine GNOME and it doesn’t seem to like my hardware ( fans are spinning fast )

my threat model involves someone trying to physically unlock my device, so I always enable disk encryption, but I wonder why Linux doesn’t support secure boot and TPM based encryption ( I know that Ubuntu has plans for the later that’s why I’m considering it rn )

I need something that keeps things updated and adobts newer standards fast ( that’s why I picked Fedora KDE in the first place ), I also use lots of graphical tools and video editing software, so I need the proprietary Nvidia drivers

Idk what to choose ಥ_ಥ ? the only one that seem to care about using hardware based encryption is Ubuntu, while other distros doesn’t support that… the problem with Ubuntu is there push for snaps ( but that can be avoided by the user )

security heads say: if you care about security, you shouldn’t be using systemd, use something like Gentoo or Alpine… yeah but do you expect me to compile my software after ? hell no

  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍
    15•4 months ago

    K, so I’m probably oversimplifying, but almost all distros should allow you to at least encrypt /home, and although I haven’t tried it myself yet, whole-disk encryption via UEFI is possible. You say your threat model is only someone trying to unlock your device, but it sounds as if you’re not worried about espionage - someone gaining access to your computer and replacing the /efi boot process with something that will harvest your password when you log in. If all you’re worried about is seizure and data protection, why isn’t disk encryption sufficient?

    If you really feel like you need TPM, Arch supports it, which means other distros do, too. Although, figuring it out for, e.g., Ubuntu of something you’ll have to research; the Arch wiki is the most fantastic source of Linux documentation on the web, and much (but not all) of it can help with other distros.

    I may be completely misunderstanding what problem you’re encountering, but (a) disk encryption is trivial to set up on both Mint and EndeavorOS installers (the two I’ve used most recently), and (b) TPM certainly seems possible from the Arch wiki.

      • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍
        2•4 months ago

        I was going off what you said:

        my threat model involves someone trying to physically unlock my device

        This doesn’t sound to me as if you’re concerned about espionage - repeated, covert, root access to your computer, for the purpose of installing software to capture your keys, so that they can steal your computer and have complete access. If someone has remote root access to your computer, you’re fucked, TPM or not; they’ll just read what they want whenever you’re logged in and using your computer.

        TPM is for when you might not have secured physical access to your computer. Like, you’re worried the NSA is going to sneak into your house while you’re out shopping, pull your HD, replace the boot loader, and re-install it before you get home.

        If you’re only worried about, say, losing a laptop, or a search & seizure at your house, an encrypted HD is good enough. TPM and a keylocked BIOS are belts-and-suspenders, but if they want to get at the data they’ll just pull the HD and run code-breaking software on it on and entirely different super-computer. TPM won’t help you at all in that case.

        Honestly, TPM is for a specific threat mode, which is much more like ongoing espionage, than simple opportunity theft. Your stated use case sounds more like the latter than the former.

          • @Sbauer
            2•4 months ago

            Because i don’t have second chances, which is why I wish there’s way to erase everything by entering a key combination… somehow… Idk… like Android has that…

            That triggered a memory for me. Apparently certain SSD(Samsung I heard of, not sure about others) always encrypt your data in hardware with a random key, this is done transparently to the OS and is otherwise unremarkable.

            What it archives though and afaik is intended for is the possibility of easily and quickly “erasing” the disk by just overwriting that encryption key a couple times, I don’t remember if that used a special tool or something but if that is useful to you it probably wouldn’t be hard to find more info on this.

            Samsung is a reasonably trustworthy company, not from US/UK, not Chinese, so if they say they have a clean implementation of this I’d trust them. Would be kinda a national security issue for them if it wasn’t seeing how Samsung is everywhere in gov an private sector in Korea.

              • @Sbauer
                1•4 months ago

                I’m speculating here, but it wouldn’t be far fetched if they designed a secure encrypted clean hardware for the government with military grade encryption as they like to call it, while the end users receives only enough encryption power to protect against normie threat actors like a spouse…etc companies have these policies where they provide a premium/quality products for businesses and governments but cheap or in many cases poorly made products to end users … like Windows Home

                I can see why you think that, but that is US centric thinking. South Korea probably cares a whole lot more about corporate security vs government security compared to the US. I don’t mean to say they don’t care about government secrets, but it’s different. No nukes, no Cold War against a superpower, instead a couple huge conglomerates basically keeping the entire GDP afloat.

                Samsung in Korea isn’t like the Samsung we know, they built everything from cars, tanks, ships, insurances, constructions(they built the burj khalifa), pharmaceuticals etc.

                There are probably a handful of conglomerates like that in South Korea and they basically built a state around them to manage their employees needs.

      • th3raid0r
        2•4 months ago

        This sounds like a lenovo machine. Or something with a similar MOK enrollment process.

        I forget the exact process, but I recall needing to reset the secureboot keys in “install mode” or something, then it would allow me to perform the MOK enrollment. If secureboot is greyed out in the BIOS it is never linux’s fault. That’s a manufacturer issue.

        Apparently, some models of Lenovo don’t even enable MOK enrolment and lock it down entirely. Meaning that you’d need to sign with Microsofts keys, not your own. The only way to do this is to be a high-up microsoft employee OR use a pre-provided SHIM from the distribution.

        https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_a_signed_boot_loader

        For that case, Ubuntu and Fedora are better because, per the Ubuntu documentation they do this by default.

        On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical’s UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.

        Once you have secureboot working on Ubuntu or Fedora, you could likely follow these steps to enable TPM+PIN - https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

        There might be some differences as far as kernel module loading and ensuring you’re using the right tooling for your distro, but most importantly, the bones of the process are the same.

        OH! And if you aren’t getting the secureboot option in the installer UI, that could be due to booting the install media in “legacy” or “MBR” mode. Gotta ensure it’s in UEFI mode.

        EDIT: One more important bit, you’ll need to be using the latest nvidia drivers with the nvidia-open modules. Otherwise you’ll need to additionally sign your driver blobs and taint your kernel. Nvidia-Open is finally “default” as of the latest driver, but this might differ on a per-distro basis.