* 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