Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2024-01-16 at 11:50 +0100, Christian Brauner wrote:
> So when we say luksSuspend we really mean block layer initiated
> freeze. The overall goal or expectation of userspace is that after a
> luksSuspend call all sensitive material has been evicted from
> relevant caches to harden against various attacks. And luksSuspend
> does wipe the encryption key and suspend the block device. However,
> the encryption key can still be available clear-text in the page
> cache. To illustrate this problem more simply:
> 
> truncate -s 500M /tmp/img
> echo password | cryptsetup luksFormat /tmp/img --force-password
> echo password | cryptsetup open /tmp/img test
> mkfs.xfs /dev/mapper/test
> mount /dev/mapper/test /mnt
> echo "secrets" > /mnt/data
> cryptsetup luksSuspend test
> cat /mnt/data

Not really anything to do with the drop caches problem, but luks can
use the kernel keyring API for this.  That should ensure the key itself
can be shredded on suspend without replication anywhere in memory.  Of
course the real problem is likely that the key has or is derived from a
password and that password is in the user space gnome-keyring, which
will be much harder to purge ... although if the keyring were using
secret memory it would be way easier ...

So perhaps before we start bending the kernel out of shape in the name
of security, we should also ensure that the various user space
components are secured first.  The most important thing to get right
first is key management (lose the key and someone who can steal the
encrypted data can access it).  Then you can worry about data leaks due
to the cache, which are somewhat harder to exploit easily (to exploit
this you have to get into the cache in the first place, which is
harder).

> This will still happily print the contents of /mnt/data even though
> the block device and the owning filesystem are frozen because the
> data is still in the page cache.
> 
> To my knowledge, the only current way to get the contents of
> /mnt/data or the encryption key out of the page cache is via
> /proc/sys/vm/drop_caches which is a big hammer.

To be honest, why is this too big a hammer?  Secret data could be
sprayed all over the cache, so killing all of it (assuming we can as
Jan points out) would be a security benefit.  I'm sure people would be
willing to pay the additional start up time of an entirely empty cache
on resume in exchange for the nicely evaluateable security guarantee it
gives.  In other words, dropping caches by device is harder to analyse
from security terms (because now you have to figure out where secret
data is and which caches you need to drop) and it's not clear it really
has much advantage in terms of faster resume for the complexity it
would introduce.

James