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

  • Lojcs@lemm.ee
    1·
    4 months ago

    In this [default] mode, Aeon will measure all of the following aspects of your systems integrity and store those measurements in your systems TPM:

    UEFI Firmware
    Secureboot state (enabled or disabled)
    Partition Table
    Boot loader and drivers
    Kernel and initrd (including kernel cmdline parameters)

    When your system starts, it will compare the current state to the measurements stored in the TPM.

    If they match, your system will boot.

    As Default Mode establishes a strong ‘chain of trust’ between a more comprehensive list of key boot components, the use of Secureboot in Default Mode can be considered optional.

    As Fallback Mode has no such measurements of boot components, Secureboot should be enabled. Disabling Secureboot in Fallback Mode leaves your system vulnerable to tampering, including attacks which may capture your passphrase when entered.

    If secure boot isn’t needed then what’s stopping an attacker from USB booting and changing the tpm parameters or pulling the luks password? Actually what’s stopping an attacker from USB booting even when secure boot is enabled? Or switching the Aeon kernel with one that won’t do the check at all and registering that with secure boot?

    A quick Google search says secure boot is not intended to protect against someone with physical access. Then why does it matter in the context of fde at all? Malware running after boot would have access to (most of the) unencrypted filesystem anyways. Edit: and if it has the privileges to modify kernel or boot loader it could do the things I wrote above too

    And it’s weird that there isn’t a mode that uses a luks password in combination to the chain of trust. Relying on the user password for protection doesn’t feel very secure since a physical attacker would have more opportunities to see it while the computer is in use than a luks password.