Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
valdis.kletnieks at vt.edu
valdis.kletnieks at vt.edu
Fri Dec 7 15:58:57 EST 2018
On Fri, 07 Dec 2018 23:13:45 +0300, Lev Olshvang said:
> Existing file encryption tools, like dm-crypt, fscrypt and eCryptfs provide
> only encryption of files only until file system is mounted. (data at rest)
> The moment it became mounted, every user of computer can try to access the
There's this thing called "threat model" - what are you trying to protect, and
who are you protecting from.
Most filesystem encryption is designed to defend against a stolen device such
as a laptop, so that the thief cannot read the data.
> I do not understand why linux kernel key belonging to only one user can not be
> used at every read/write to decrypt data only for him?
> Evidently I do not understand the reason why mount of user home directory
> during login (Ubunty's eCrypfs) do not use user's session kernel key to
> allow only holder of this key to encrypt/decrypt files?
Note - a *session* kernel key doesn't work, because those change session to
session, and thus there's no guarantee that they'll function as a key to
decrypt files that last across multiple sessions. For a thought experiment,
figure out how to have 2 sessions with different keys to both be able to
decrypt the same file. A lot harder than it looks. So you end up using a
reasonably permanent key for the files.
Now you're talking a different threat model - two users who distrust each other
on the same powered-on system. However, this proposed crypto behavior doesn't
provide any *actual* additional security over and above the already existing
permission bits and ACLs.
Consider two users A and B, and a file /home/a/secretfile that's owned by A and
mode 600. B is an attacker, who can't read secretfile because of the
Now let's say that B gets root. Now they can bypass the permissions and read
secretfile. However, adding a permanent kernel key and crypto doesn't add
security, because unless you have a whole mess of other things in place (for
instance SELinux) preventing root from doing so, B-as-root can just 'sudo A
/bin/bash' and get access.
So the short answer of why we don't do it - because you have to do a lot of
*other* hardening to make it impossible to bypass it, and that adds to the
total cost (in sysadmin time and other factors). So unless you have some
*really* valuable data to protect it's not worth the effort.
And usually, it's a heck of a lot cheaper to just buy a whole second server so
A and B are on different hardware which neutralizes things like Spectre attacks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 486 bytes
Desc: not available
More information about the Kernelnewbies