Kernel Newbies archive on lore.kernel.org
 help / Atom feed
* Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
@ 2018-12-07 20:13 Lev Olshvang
  2018-12-07 20:58 ` valdis.kletnieks
  0 siblings, 1 reply; 3+ messages in thread
From: Lev Olshvang @ 2018-12-07 20:13 UTC (permalink / raw)
  To: kernelnewbies

[-- Attachment #1: Type: text/html, Size: 1280 bytes --]

<div xmlns="http://www.w3.org/1999/xhtml">Hi All,</div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Existing file encryption tools, like dm-crypt, fscrypt and eCryptfs provide only encryption of files only until file system is mounted.  (data at rest)</div><div xmlns="http://www.w3.org/1999/xhtml">The moment it became mounted, every user of computer can try to access the data.</div><div xmlns="http://www.w3.org/1999/xhtml">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?  </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">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?  </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div><div xmlns="http://www.w3.org/1999/xhtml">Thx,</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"> </div><div xmlns="http://www.w3.org/1999/xhtml"> </div>

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
  2018-12-07 20:13 Why existing filesystem encryption tools do not limit run-time file access while user/session might be used? Lev Olshvang
@ 2018-12-07 20:58 ` valdis.kletnieks
  2018-12-08 20:40   ` Lev Olshvang
  0 siblings, 1 reply; 3+ messages in thread
From: valdis.kletnieks @ 2018-12-07 20:58 UTC (permalink / raw)
  To: Lev Olshvang; +Cc: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 2575 bytes --]

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 #1.2: Type: application/pgp-signature, Size: 486 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?
  2018-12-07 20:58 ` valdis.kletnieks
@ 2018-12-08 20:40   ` Lev Olshvang
  0 siblings, 0 replies; 3+ messages in thread
From: Lev Olshvang @ 2018-12-08 20:40 UTC (permalink / raw)
  To: valdis.kletnieks; +Cc: kernelnewbies

[-- Attachment #1: Type: text/html, Size: 5054 bytes --]

<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&gt; 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" &lt;valdis.kletnieks@vt.edu&gt;:</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>

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-07 20:13 Why existing filesystem encryption tools do not limit run-time file access while user/session might be used? Lev Olshvang
2018-12-07 20:58 ` valdis.kletnieks
2018-12-08 20:40   ` Lev Olshvang

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org kernelnewbies@archiver.kernel.org
	public-inbox-index kernelnewbies


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/ public-inbox