3 ms·

This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced sce

by yyyk 5y ago

This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0]. However, I do not think Poettering's proposal is going to even annoy Mossad-level operations. The same people who can steal your harddrive and put it back in without notice, can for example replace your mouse with a BadUSB device and get all the info that way. Once they got hardware access, and were able to return it without the owner noticing, they have multiple ways of getting what they want. On Linux we can't be assured of controlling the hardware Apple-style. So this is a proposal which probably doesn't stop the advanced and rare scenarios it thinks it stops. In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). IMHO, the cost-benefit ratio for splitting the system isn't good enough. We should try a simpler solution with the main purpose of stopping the basic scenario. Maybe dm-crypt everything, despite the minor speed loss? Or use fs-level authentication/encryption a-la fscrypt? Either solution still allows people who want to split the system to do so. [0] https://www.theregister.com/2009/11/06/mossad_syria_trojan_hack/ https://www.theregister.com/2009/11/06/mossad_syria_trojan_h... * The authenticated base system, the encrypted base system, and at least one encrypted home directory. In most system there will also be an encrypted swap partition.

JonathonW 5y ago
> In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get away with splitting the filesystem up similarly to Poettering's proposal. (They don't go quite as far; they have a signed, sealed system volume plus a single user volume rather than Poettering's multiple user volumes, but the split is still there and therefore runs into the same issue of space allocation.) [1] https://en.wikipedia.org/wiki/Apple_File_System#Partition_scheme https://en.wikipedia.org/wiki/Apple_File_System#Partition_sc...
- yyyk 5y ago
  I think btrfs subvolumes can do this? However btrfs doesn't (yet?) support encryption.
  - Iolaum 5y ago
    I am using BTRFS and FDE encryption right now on Fedora Silverblue for a year if not more. And like the post says, I am typing two passwords.
    - yyyk 5y ago
      I'm talking about filesystem level support, not block level support. FDE is block level and of course will work on any supported filesystem including btrfs. What btrfs doesn't do is support encryption inside the filesystem a la fscrypt - where we can encrypt specific directories - or ZFS encryption, where we can encrypt specific filesystems inside a pool. If I understand btrfs right, supporting encryption/verification on subvolume or directory levels would allow splitting the system so only part of it is encrypted/verified (so we get Poettering's performance gains), while avoiding space issues between the subvolumes. Also, using only one password is easy on fscrypt style systems, though this may not suit everyone's threat model.
      - curt15 5y ago
        fscrypt support for btrfs is apparently under development; see the most recent comments at https://github.com/btrfs/btrfs-todo/issues/25 https://github.com/btrfs/btrfs-todo/issues/25
uzakov 5y ago
> IMHO, the cost-benefit ratio for splitting the system isn't good enough. A while ago I wrote a guide on a system that has good cost-benefit ratio in terms of security and amount of effort required. It is a bit outdated for 2021 but overall still good imho https://uzakov.io/2017/05/08/pretty-good-setup-pgs/ https://uzakov.io/2017/05/08/pretty-good-setup-pgs/

by yyyk 5y ago

JonathonW 5y ago

> In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get away with splitting the filesystem up similarly to Poettering's proposal. (They don't go quite as far; they have a signed, sealed system volume plus a single user volume rather than Poettering's multiple user volumes, but the split is still there and therefore runs into the same issue of space allocation.) [1] https://en.wikipedia.org/wiki/Apple_File_System#Partition_scheme https://en.wikipedia.org/wiki/Apple_File_System#Partition_sc...

yyyk 5y ago
I think btrfs subvolumes can do this? However btrfs doesn't (yet?) support encryption.
- Iolaum 5y ago
  I am using BTRFS and FDE encryption right now on Fedora Silverblue for a year if not more. And like the post says, I am typing two passwords.
  - yyyk 5y ago
    I'm talking about filesystem level support, not block level support. FDE is block level and of course will work on any supported filesystem including btrfs. What btrfs doesn't do is support encryption inside the filesystem a la fscrypt - where we can encrypt specific directories - or ZFS encryption, where we can encrypt specific filesystems inside a pool. If I understand btrfs right, supporting encryption/verification on subvolume or directory levels would allow splitting the system so only part of it is encrypted/verified (so we get Poettering's performance gains), while avoiding space issues between the subvolumes. Also, using only one password is easy on fscrypt style systems, though this may not suit everyone's threat model.
    - curt15 5y ago
      fscrypt support for btrfs is apparently under development; see the most recent comments at https://github.com/btrfs/btrfs-todo/issues/25 https://github.com/btrfs/btrfs-todo/issues/25

uzakov 5y ago

> IMHO, the cost-benefit ratio for splitting the system isn't good enough. A while ago I wrote a guide on a system that has good cost-benefit ratio in terms of security and amount of effort required. It is a bit outdated for 2021 but overall still good imho https://uzakov.io/2017/05/08/pretty-good-setup-pgs/ https://uzakov.io/2017/05/08/pretty-good-setup-pgs/