FSCRYPT's Inline Encryption Support Updated For Possible Inclusion In Linux 5.6

[phoronix]

Phoronix: FSCRYPT's Inline Encryption Support Updated For Possible Inclusion In Linux 5.6

Back in October we reported on work done by Google on FSCRYPT inline encryption support for allowing the Linux file-system encryption framework to handle the encrypt/decrypt more optimally for modern mobile SoCs with inline encryption hardware. It's looking like that work might be ready to go now for Linux 5.6 after missing out on the 5.5 cycle...

http://www.phoronix.com/scan.php?page=news_item&px=FSCRYPT-Inline-Encryption-5.6

[Guest]

How is this any different from LUKS? Why didn't they just use that?

[Laser]

How is this any different from LUKS? Why didn't they just use that?

The issues are completely unrelated that's why.

LUKS: System that adds a header to block devices to manage encryption and decryption on them, where multiple keys can be stored, the algorithm needed for decryption is specified so that it's not needed every time etc.

This: a change in the file system encryption framework so that filesystems that handle encryption themselves (ext4 can do this for example) can use modern SoCs better (how it does it in detail I have no clue). File system encryption like this is helpful if you want to simultaneously grant multiple users a flexible amount of encrypted storage without them being able to see another user's files. Think encrypted /home/user that root cannot see but is still able to mount. I also suspect that it helps with Android security where every app is run by their own user and that's why Google is interested in enhancing performance on SoCs.

[Guest]

The issues are completely unrelated that's why.

LUKS: System that adds a header to block devices to manage encryption and decryption on them, where multiple keys can be stored, the algorithm needed for decryption is specified so that it's not needed every time etc.

This: a change in the file system encryption framework so that filesystems that handle encryption themselves (ext4 can do this for example) can use modern SoCs better (how it does it in detail I have no clue). File system encryption like this is helpful if you want to simultaneously grant multiple users a flexible amount of encrypted storage without them being able to see another user's files. Think encrypted /home/user that root cannot see but is still able to mount. I also suspect that it helps with Android security where every app is run by their own user and that's why Google is interested in enhancing performance on SoCs.

Ah, I see. I believe the "use modern SoCs better" part refers to AES NI instruction support on some of the newer ARM CPUs.

[anarki2]

The issues are completely unrelated that's why.

LUKS: System that adds a header to block devices to manage encryption and decryption on them, where multiple keys can be stored, the algorithm needed for decryption is specified so that it's not needed every time etc.

This: a change in the file system encryption framework so that filesystems that handle encryption themselves (ext4 can do this for example) can use modern SoCs better (how it does it in detail I have no clue). File system encryption like this is helpful if you want to simultaneously grant multiple users a flexible amount of encrypted storage without them being able to see another user's files. Think encrypted /home/user that root cannot see but is still able to mount. I also suspect that it helps with Android security where every app is run by their own user and that's why Google is interested in enhancing performance on SoCs.

Flexible my arse. There's still no backup and recovery, to begin with. We've been waiting for YEARS.

Password changes for centrally managed users (i.e. SSSD) are not handled. If the old password is entered, the OS will not let her in. If the new password is entered, fscrypt will not unlock the home dir. So the moment the user changes her password, she's locked out. Way to go.

It also requires userspace support for some idiotic reason, because of the "flexible" way fscrypt works. E.g. it breaks Docker. It breaks Firefox downloads. Not always, just sometimes. I just don't get it. If the architecture causes such random failures, it's definitely well designed.

The whole concept of policies and protectors is a PITA to work with, because giving me a path is just too traditional, how about a GUID?

The whole setup is cumbersome and impossible to automate. Not even with quirks like this. Why? Because the fscrypt CLI won't let you. It really WANTS you to type

sudo fscrypt metadata add-protector-to-policy --protector=/:${fscrypt_protector} --policy=/:${fscrypt_policy}

and other cr@p from the stdin. Every time you add a new user or something. No other way. Because it's "flexible".

Not to mention that anything less than FDE is pointless to begin with. What's the point of encrypting 90% of your files? What about the remaining 10%? Especially when you're forced to work in that 10% because fscrypt breaks your working environment, like Docker? You might as well not use encryption at all. At least that wouldn't be this buggy and wouldn't be such a maintenance burden.

I could go on with the shortcomings and broken/missing features of fscrypt, but why bother. I wasted WAY too much time on it already. All I can suggest you guys is to just use LUKS with Clevis TPM2 unlock and stay a f*ck away from fscrypt. It solves nothing and breaks a hell of a lot. A complete waste of time and one of my worst decisions in recent years for sure. Thankfully, it's only a matter of weeks/months before we completely phase it out.

[ebiggers]

There's still no backup and recovery, to begin with.

If you're talking about backing up encrypted files without the key, this is something that's hard to implement, and not many people have actually asked for since files can be backed up with the key instead. In fact there is no open issue at https://github.com/google/fscrypt/issues for this. So if this is something you want, perhaps you should request it as a feature to show interest.

Recovery passphrase support is being worked on at https://github.com/google/fscrypt/pull/167; you're welcome to test it and give feedback.

Password changes for centrally managed users (i.e. SSSD) are not handled. If the old password is entered, the OS will not let her in. If the new password is entered, fscrypt will not unlock the home dir. So the moment the user changes her password, she's locked out. Way to go.

If a user's password is changed locally, their login protector will be updated if pam_fscrypt is properly configured. Note that PAM configuration is the responsibility of the Linux distribution or the system administrator; there's a limit to what fscrypt itself can do to prevent bad PAM configurations.

If a user's password is changed remotely, I don't believe your LUKS or eCryptfs password would be changed either. You're welcome to look into how this could be implemented, if you're interested in it; no one else has asked for it.

It also requires userspace support for some idiotic reason, because of the "flexible" way fscrypt works. E.g. it breaks Docker. It breaks Firefox downloads. Not always, just sometimes. I just don't get it. If the architecture causes such random failures, it's definitely well designed.

These problems are caused by the way that the original fscrypt API used the kernel keyrings. There is a new API available in Linux v5.4 that fixes this, and https://github.com/google/fscrypt/pull/148 adds the corresponding support to the 'fscrypt' userspace tool.

The whole concept of policies and protectors is a PITA to work with, because giving me a path is just too traditional, how about a GUID?

The whole setup is cumbersome and impossible to automate. Not even with quirks like this. Why? Because the fscrypt CLI won't let you. It really WANTS you to type

sudo fscrypt metadata add-protector-to-policy --protector=/:${fscrypt_protector} --policy=/:${fscrypt_policy}

and other cr@p from the stdin. Every time you add a new user or something. No other way. Because it's "flexible".

I think all the commands support non-interactive use. If you find otherwise in some case, please report it as a bug.

I'm planning to simplify the syntax for adding an extra protector, which was also requested at https://github.com/google/fscrypt/issues/178. To be clear, this is an advanced usage, though. For the common single-protector usage, people can just use 'fscrypt encrypt DIR' -- and there is an open pull request to make this auto-generate a recovery passphrase which should handle a lot of the cases where people might want a second protector.

Not to mention that anything less than FDE is pointless to begin with. What's the point of encrypting 90% of your files?

FDE is the better solution in cases where a whole filesystem can be protected with one password and unlocked / locked all at once. If that fits your use case, I encourage you to use FDE. fscrypt is for cases where more granular encryption is needed, e.g. different encryption per user on the same filesystem.

Please also understand that the largest users of ext4/f2fs encryption are Android and Chrome OS, which don't use the https://github.com/google/fscrypt tool. So there's been a lot more focus on the kernel part, and no one is really paying for development of the userspace tool for general-purpose Linux distros. So, contributions are greatly appreciated, especially if you have a concrete use case.

[pal666]

Ah, I see. I believe the "use modern SoCs better" part refers to AES NI instruction support on some of the newer ARM CPUs.

i believe aes ni instructions do not require interface change (and they are available on amd64 cpus for long time). what does require new interface is "write these block while encrypting them with these settings" hardware interface

[pal666]

Not to mention that anything less than FDE is pointless to begin with. What's the point of encrypting 90% of your files?

what is the point of encrypting /bin/* ? what is the point of encrypting my home with your key?