Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?

Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?

[Lev Olshvang]

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

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

_______________________________________________
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?

[valdis.kletnieks]

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

Re: Why existing filesystem encryption tools do not limit run-time file access while user/session might be used?

[Lev Olshvang]

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

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

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