<div xmlns="http://www.w3.org/1999/xhtml">Hi Valdis,</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">I am afraid I did not clearly explain myself.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">I want run-time protection of one special user from any other users of the same board ( embedded device).</div><div xmlns="http://www.w3.org/1999/xhtml">This user will  user import a key from HSM to a keyring , and LSM will provide only him access to HSM.</div><div xmlns="http://www.w3.org/1999/xhtml">Actually  I am not sure whether LSM is a proper mechanism to do it, I will be glad if you can enlighten me,</div><div xmlns="http://www.w3.org/1999/xhtml">But I am continue to my point</div><div xmlns="http://www.w3.org/1999/xhtml">This specific user A starts a service daemon and receive key from HSM which he put as the session key into the keyring and use it to decrypt files.</div><div xmlns="http://www.w3.org/1999/xhtml">When superpowered user  B will  su to  became user A he will discover himself in a different session which does not have user A key.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">So the trick with    B> sudo A -c /bin./bash  car secretfile  will not work.</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">I think many developers like me already thought of this method, I wonder why eCrypts does not provide such solution?</div><div xmlns="http://www.w3.org/1999/xhtml">Perhaps I have fundamental issue about exclusive HSM access, whether it is possible?</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">ThanX for you time.</div><div xmlns="http://www.w3.org/1999/xhtml">Please continue to share your thoughts with me.</div><div xmlns="http://www.w3.org/1999/xhtml">Lev,</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">07.12.2018, 23:59, "valdis.kletnieks@vt.edu" <valdis.kletnieks@vt.edu>:</div><blockquote xmlns="http://www.w3.org/1999/xhtml" type="cite"><p>On Fri, 07 Dec 2018 23:13:45 +0300, Lev Olshvang said:</p><blockquote> Existing file encryption tools, like dm-crypt, fscrypt and eCryptfs provide<br /> only encryption of files only until file system is mounted.  (data at rest)<br /> The moment it became mounted, every user of computer can try to access the<br /> data.</blockquote><p><br />There's this thing called "threat model" - what are you trying to protect, and<br />who are you protecting from.<br /><br />Most filesystem encryption is designed to defend against a stolen device such<br />as a laptop, so that the thief cannot read the data.<br /> </p><blockquote> I do not understand why linux kernel key belonging  to only one user can not be<br /> used at every read/write to decrypt data only for him?  </blockquote><p> </p><blockquote> Evidently I do not understand the reason why mount of user home directory<br /> during login (Ubunty's eCrypfs) do not  use  user's  session kernel key to<br /> allow only holder of this key to encrypt/decrypt files?<br /></blockquote><p><br />Note - a *session* kernel key doesn't work, because those change session to<br />session, and thus there's no guarantee that they'll function as a key to<br />decrypt files that last across multiple sessions. For a thought experiment,<br />figure out how to have 2 sessions with different keys to both be able to<br />decrypt the same file. A lot harder than it looks. So you end up using a<br />reasonably permanent key for the files.<br /><br />Now you're talking a different threat model - two users who distrust each other<br />on the same powered-on system. However, this proposed crypto behavior doesn't<br />provide any *actual* additional security over and above the already existing<br />permission bits and ACLs.<br /><br />Consider two users A and B, and a file /home/a/secretfile that's owned by A and<br />mode 600. B is an attacker, who can't read secretfile because of the<br />permissions.<br /><br />Now let's say that B gets root. Now they can bypass the permissions and read<br />secretfile. However, adding a permanent kernel key and crypto doesn't add<br />security, because unless you have a whole mess of other things in place (for<br />instance SELinux) preventing root from doing so, B-as-root can just 'sudo A<br />/bin/bash' and get access.<br /><br />So the short answer of why we don't do it - because you have to do a lot of<br />*other* hardening to make it impossible to bypass it, and that adds to the<br />total cost (in sysadmin time and other factors). So unless you have some<br />*really* valuable data to protect it's not worth the effort.<br /><br />And usually, it's a heck of a lot cheaper to just buy a whole second server so<br />A and B are on different hardware which neutralizes things like Spectre attacks<br />as well....<br /> </p></blockquote>