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....
Attachment:
pgp8yRRTGJvC9.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
