Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
FruityWelsh opened this issue Feb 8, 2023 · 3 comments
Closed
Labels

Comments

@FruityWelsh
Copy link

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
Copy link
Member

josephlr commented Feb 9, 2023

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
Copy link
Author

@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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants