Closed Redsandro closed 5 years ago
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.
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?
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.
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 byuser1
, 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:
The problem is with this combination of facts:
user1
assumes exclusive key knowledge is exclusive file accessCurrently 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:
*) Similar to how ssh refuses to function when
~/.ssh/
contents are not mode 600Related: #61 #66 #111