google / fscrypt

Go tool for managing Linux filesystem encryption
Apache License 2.0
876 stars 97 forks source link

Support for individual files to assigned instead of directory level #373

Closed FruityWelsh closed 1 year ago

FruityWelsh commented 1 year ago

Are there any technical limitations that would prevent fscrypt to be applied on a per-file basis instead of a per-directory basis?

The primary one I can think of is .fscrypt directory, though my first though is allowed for the use of xattrs for those instead.

josephlr commented 1 year ago

The limitation here is mostly just a reflection of the underlying kernel API. FS_IOC_SET_ENCRYPTION_POLICY can only apply a new policy to an empty directory. Thus, this userspace tool has the same restriction.

This is almost always what you want though, because just having filesystem-level encryption on an individual file would not encrypt the filename, and we want things to be secure by default. You can move an individual encrypted file out of an encrypted directory, but then fscrypt unlock will no longer work.

The primary one I can think of is .fscrypt directory, though my first though is allowed for the use of xattrs for those instead.

This might be a misunderstanding of how the /.fscrypt directory works. That directory is for storing policies/protectors for the filesystem not for a specific directory. The location of the data in that directory will not affect if fscrypt can work on an individual file.

FruityWelsh commented 1 year ago

@josephlr I definitely get wanting to encrypt the filename as well as the data, but that would seem reasonably hidden if the directory was encrypted. So in the case in which the filename is not sensitive info the dir could be unencrypted, but the contents of the file would be.

Yes, that was my hopeful misunderstanding on what the .fscrypt file did, thank you for clearing that up too!

That said, thank you for the info and agreed it seems the issue is at the kernel API first

ebiggers commented 1 year ago

It probably would be possible for the kernel to be changed to allow setting an encryption policy on an empty regular file, but there's been no good reason to allow it so far.

If you really want to, you can already create an encrypted directory and a file within it, then move that file into an unencrypted directory. In that case, you do in fact end up with a standalone encrypted file.

However, as @josephlr mentioned, an issue with standalone encrypted files is that fscrypt unlock doesn't work. That's because in order to figure out which encryption policy to unlock, it's necessary to open the file to query its encryption policy. But the kernel does not allow encrypted regular files to be opened without their encryption key being present; only directories can be.