Announcement

Collapse
No announcement yet.

Improved Fscrypt Sent In For Linux 5.4 To Offer Better Native File Encryption Handling

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Improved Fscrypt Sent In For Linux 5.4 To Offer Better Native File Encryption Handling

    Phoronix: Improved Fscrypt Sent In For Linux 5.4 To Offer Better Native File Encryption Handling

    In addition to submitting the FS-VERITY file authentication code for Linux 5.4, Google's Eric Biggers has sent out his big update to the fscrypt file encryption framework for this next kernel revision...

    http://www.phoronix.com/scan.php?pag...-For-Linux-5.4

  • #2
    Too little too late. These patches by no means are guaranteed to be merged, and even then, it might take YEARS to be pulled down into distros, especially LTS releases. We tried to use fscrypt, we really did. But there are just way too many issues and missing management options. It's just ridiculous how many quirks it requires:

    https://github.com/noobient/noobuntu...obuntu-encrypt

    And it's still causing more troubles than what it resolves.

    We're trying to figure out a sane way to unlock LUKS with TPM, then bye-bye fscrypt.
    Last edited by anarki2; 09-18-2019, 07:30 AM.

    Comment


    • #3
      Too little too late. These patches by no means are guaranteed to be merged, and even then, it might take YEARS to be pulled down into distros, especially LTS releases. We tried to use fscrypt, we really did. But there are just way too many issues and missing management options. It's just ridiculous how many quirks it requires:
      It's been merged now, so it will be in 5.4 which is rumored to be the next LTS kernel, and might be the kernel that will be chosen for Ubuntu 20.04 LTS. There's also a pull request for the userspace side open already.

      And in any case, the long lead time for kernel changes is no reason not to improve things.

      Have you reported the problems you're having to the issue tracker?

      Comment


      • #4
        Originally posted by ebiggers View Post

        It's been merged now, so it will be in 5.4 which is rumored to be the next LTS kernel, and might be the kernel that will be chosen for Ubuntu 20.04 LTS. There's also a pull request for the userspace side open already.

        And in any case, the long lead time for kernel changes is no reason not to improve things.

        Have you reported the problems you're having to the issue tracker?
        They've been reported and asked about many times in the past, yes.

        Other features are "planned" and have been for a long time. What bugs me the mos is that I cannot enable encryption for existing directories. Much like LUKS, you either enable it during partitioning, or forget about it. The inflexibility is stunning. It's 2019 and Linux encryption still is a mess. Other OSes figured this out a decade ago.

        Comment


        • #5
          They've been reported and asked about many times in the past, yes.
          What are the issue numbers?

          Other features are "planned" and have been for a long time. What bugs me the mos is that I cannot enable encryption for existing directories. Much like LUKS, you either enable it during partitioning, or forget about it. The inflexibility is stunning. It's 2019 and Linux encryption still is a mess. Other OSes figured this out a decade ago.
          I'm afraid this is fundamentally a bad idea on any OS. The problem is that due to the nature of modern filesystems and storage devices, as well as previous usage of the directory, the original unencrypted files (or portions thereof) may still be recoverable from disk, even if you try to delete and/or overwrite the original files. That defeats the point of encryption.

          The only model that actually makes sense in general is one where your data is encrypted from the beginning. That's what dm-crypt/LUKS requires, and it's also the model used by Android and Chrome OS which also use the fscrypt kernel feature.

          That being said, there *are* some special cases where encrypting an existing directory could make some sense, like if the directory contains no sensitive data yet (e.g. a just-created home directory with generic dotfiles only), or if you're migrating to a different encryption policy. So we'll probably end up adding a convenience command for it at some point anyway, which would copy your files into a new directory and replace the original directory for you. But we'll need to be very careful in how it's documented and what warnings and advice are given.

          Comment

          Working...
          X