What are the thoughts on encryption in fedora

What are the thoughts on new tpm backed disk encryption and implementation of systemd- homed in gnome with tech fund.

From the :

What are We Funding

  1. Encrypt User Home Directories Individually: Implementation of systemd-homed backend to encrypt user home directories, bolstering security measures.
  2. Increase Range and Quality of Hardware Support: Optimization of GNOME desktop for diverse input methods and display devices, along with performance improvements.
  3. Modernize Platform Infrastructure: Refinement of desktop notifications API and modernization of GTK CSS engine, among other platform updates.
  4. Improve Quality Assurance and Development Tooling: Enhancement of GNOME OS and related tooling to facilitate continuous integration testing and streamline development processes.
  5. Improve State and Compatibility of Accessibility: Overhaul of accessibility stack to ensure compatibility with modern technologies such as Wayland and Flatpak, along with advocacy for accessibility integration in software development practices.
  6. Design a New Accessibility Stack for Linux Desktop: Creation of new accessibility protocols to replace outdated components, promoting compatibility with sandboxed applications and modern security standards.
  7. Maintenance and Modernization of Security Components: Upgrading and maintenance of security-related components like Seahorse, Keyring, and libsecret, incorporating essential security features and enhancements.
  8. Secure APIs for Wayland/Flatpak: Development of secure APIs for accessing resources and user data in Wayland and sandboxed applications, ensuring robust security measures for the Linux desktop environment.

From Phoronix “https://www.phoronix.com/news/GNOME-Better-Homed” :

GNOME developers have also been busy working on features like improving the systemd-homed integration and beginning to work on mock-ups for an OS installer.

This Week In GNOME is out with their latest installment to highlight activity for the week. Some of this week’s milestones include:

  • Thanks to the Sovereign Tech Fund efforts, there is work on getting a FileChooser portal implementation working with the Nautilus file manager.

  • The first iteration of the work to make systemd-homed secure when used in combination with desktop environments is now finished.

  • Systemd-homed “secure locking” is now wired up for GNOME Shell and GDM where the home directory is re-encrypted and the key is evicted fro memory.

  • The first beta release of TypeScript bindings for GNOME.

  • Improved WebDAV interoperability in GNOME online accounts.

As for your other comment :

It’s optional, and has been available on Linux for a long time. So You will need to elaboratre on what you are conveying here :thinking:

I’ll only use it when it just-works without barely doing anything.

My experience with LUKS, dm-crypt, and SSD trim in the past was too annoying to reproduce, slower even with CPU AES on NVMe, and my actual secret files (like password databases) are already encrypted by their own means. I don’t bother with full-disk encryption and see no appeal to yet.

However I did like that when I installed Windows 11 Insider that it automatically Bitlocker’d the drive in the background without me knowing it up until I was trying to tweak something and it warned me to disable Bitlocker. That’s how full-disk encryption should be if offered as a default in an OS! It should just-happen as a low-priority background task, or automatically be done install-time with the TPM2 link and no visibility of it. Android’s been doing it subtly for years.

If I have to enter a passphrase or anything at boot time, it’s getting reinstalled unencrypted real quick :stuck_out_tongue:

You named both implementations of Encryption that are fairly insecure. Both Bilocker and Android versions give you no visibility on the key for the encryption. Which means you have nothing at all.

With Luks it’s done at install time. So it’s not in the way at all. You have ownership of the key.

Big Difference.

With disk encryption I’m more interested in protecting my data from unauthorized users (like someone jacking my phone or laptop at a coffee shop). If I don’t have the key, nobody else does either (besides the main company offering the OS I guess, and if they have to be involved to unlock my device I’m sure I’d have bigger issues going on). Worst-case if I lost the key or the TPM decided to clear itself, I’d just reinstall from backups, along with never trusting that implementation again and going unencrypted.

I like the idea of owning my own key, but I’m not entering a passphrase every boot on a computer in my house that likely isn’t getting stolen. If Luks hooks up to TPM on Linux at install-time, requires nothing to type on boots, and no manual maintenance, I might be fine with it as long as it lets me trim SSDs too (I’m fine with adversaries potentially knowing I have disk encryption or whatever trimmed cells might leak as long as they can’t see the data or get a key from it)

I believe you’ve missed my point. I digress.

I understand both @Espionage724 and @hamrheadcorvette point of view.

On one hand there’s full control of the encryption/recovery key, on the other hand there’s the annoyance of needing to enter the encryption paraphrase at every boot/reboot. And if the system is being used by multiple users, each of them has to know the key.

What are your opinions of macOS’s FileVault implementation? AFAIK the disk is being encrypted with the admin user’s initial password, you have an additional recovery key if you forget your password, user can change its password (and in turn the cryptographic keys) without requiring re-encryption of the entire volume, and each user’s login password unlocks the encrypted disk.

I really think fedora should enable encryption more prominently and also a systemdhomed enabled by default for all users.

1 Like