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....