Set mode 0700 for encrypted directory by default

[Redsandro]

fscrypt leaks unencrypted files to other users

While Ubuntu 18.04+ removed (out of the box) support for ecryptfs and advised the use of fscrypt in its release notes, the default behavior of fscrypt is actually quite dangerous in combination with the default umask setting of most distros.

The user logically assumes their files are only readable by themselves when they are protected by their login password or custom passphrase. However, they actually become readable by everyone. When user1 unlocks their encrypted home, any other user can read encrypted files when they are being touched by user1, and they stay readable until the kernel cache expires.

The adversary can watch and wait until enough files have been touched to create a raw copy of the contents of user1's home.

The problem, although this did not happen with ecryptfs iirc, seems to be related to kernel caching.

@ebiggers said:

This is a known issue with filesystem encryption in the kernel: the caches that allow encrypted files to be accessed are systemwide

The problem is with this combination of facts:

• user1 assumes exclusive key knowledge is exclusive file access
• In reality, decoded files can be read by anyone with read permission
• Default umask is usually 022 - read access for everyone
• fscrypt doesn't enforce umask of 077
• Any actor gaining any kind of access can read all your files as soon as you access them.

Currently fscrypt is good for encrypting data on cold storage. But when storage is online, even running a docker container as an unprivileged user becomes a danger, given the many many many security holes in docker containers, and the sandbox-escaping exploits that show up every now and then. Even your unprivileged user can set a watch and wait for file access to read contents.

LUKS full disk encryption is even more sensitive to the same unprivileged user or docker-breakout scenario, because the access is not time limited like the kernel cache. Last time I checked, ecryptfs did not have this problem. So while fscrypt is superior in performance, I'm wondering if ecryptfs is still superior in actual security?

Either way, I'm thinking fscrypt should:

1. Enforce umask 007*
2. Recommend umask 077
3. Set mode 700 for target directory
4. Warn about this issue when you run the encrypt command

*) Similar to how ssh refuses to function when ~/.ssh/ contents are not mode 600

Related: #61 #66 #111

[ebiggers]

Actually, the ecryptfs cache is systemwide too. I.e., all processes have the same "view" of an ecryptfs mountpoint. The difference is that the ecryptfs-setup-private script, which is part of ecryptfs-utils (not the kernel), sets mode 0700 on the encrypted directory. The solution for fscrypt is the same: use mode 0700. I agree that fscrypt encrypt should probably do that by default.

[Redsandro]

Thanks for the quick response. The ecryptfs directory is indeed 0700. Not sure about the files within. I messed with them too much to know what the default state was. But iirc files in decrypted home were still 07xx. Does ecryptfs map this somehow, or were those files also readable by other users?

[ebiggers]

Directory mode 0700 denies path lookups by other users, so other users can't get access to files in the directory, even if they have a more permissive mode.

In more detail, ecryptfs home directory encryption in Ubuntu puts the encrypted files in /home/.ecryptfs/$USER/.Private, which has mode 0700. When unlocked it's mounted with ecryptfs to /home/$USER. Thus /home/$USER gets mode 0700 too. If you chmod it to 0755, other users can access your ecryptfs encrypted files while you're logged in.

So there's nothing special going on; it's just standard UNIX file permissions.