Re: Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
Hi Valdis, I am afraid I did not clearly explain myself. I want run-time protection of one special user from any other users of the same board ( embedded device).This user will user import a key from HSM to a keyring , and LSM will provide only him access to HSM.Actually I am not sure whether LSM is a proper mechanism to do it, I will be glad if you can enlighten me,But I am continue to my pointThis 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.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. So the trick with B> sudo A -c /bin./bash car secretfile will not work. I think many developers like me already thought of this method, I wonder why eCrypts does not provide such solution?Perhaps I have fundamental issue about exclusive HSM access, whether it is possible? ThanX for you time.Please continue to share your thoughts with me.Lev, 07.12.2018, 23:59, "valdis.kletni...@vt.edu" :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, andwho are you protecting from.Most filesystem encryption is designed to defend against a stolen device suchas 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 tosession, and thus there's no guarantee that they'll function as a key todecrypt files that last across multiple sessions. For a thought experiment,figure out how to have 2 sessions with different keys to both be able todecrypt the same file. A lot harder than it looks. So you end up using areasonably permanent key for the files.Now you're talking a different threat model - two users who distrust each otheron the same powered-on system. However, this proposed crypto behavior doesn'tprovide any *actual* additional security over and above the already existingpermission bits and ACLs.Consider two users A and B, and a file /home/a/secretfile that's owned by A andmode 600. B is an attacker, who can't read secretfile because of thepermissions.Now let's say that B gets root. Now they can bypass the permissions and readsecretfile. However, adding a permanent kernel key and crypto doesn't addsecurity, because unless you have a whole mess of other things in place (forinstance 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 thetotal 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 soA and B are on different hardware which neutralizes things like Spectre attacksas well ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
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 pgp7Y1KdmBCUi.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
Hi All, 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.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? Thx,Lev ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
