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
data.
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
permissions.
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
as well....
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
