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

[Adrian Vovk <adrianvovk@gmail.com>]

On 1/17/24 01:17, Theodore Ts'o wrote:
> What is the threat model that you are trying to protect against?  If
> the attacker has access to the memory of the suspended processor, then
> number of things you need to protect against becomes *vast*.  For one
> thing, if you're going to blow away the LUKS encryption on suspend,
> then during the resume process, *before* you allow general user
> processes to start running again (when they might try to read from the
> file system whose encryption key is no longer available, and thus will
> be treated to EIO errors), you're going to have to request that user
> to provide the encryption key, either directly or indirectly.

The threat we have in mind are cold-boot attacks, same as the threat 
that dm-crypt protects against when it lets us wipe the LUKS volume 
key.We want to limit the amount of plain-text user data an attacker can 
acquire from a suspended system.

As I mention elsewhere in this thread, the key word for me is "limit". 
I'm not expecting perfect security, but I'd like most plaintext file 
contents to be removed from memory on suspend so that an attacker cannot 
access most recently accessed files. Ideally it would be "all" not 
"most", of course, but I'll happily take what's feasible

> And if the attacker has access to the suspended memory, is it
> read-only access, or can the attacker modify the memory image to
> include a trojan that records the encryption once it is demanded of
> the user, and then mails it off to Moscow or Beijing or Fort Meade?

Yes, it's read-only access.

If the attacker has write access to the memory image while the system is 
suspended then it's complete game-over on all fronts. At that point they 
can completely replace the kernel if they so choose. This is not 
something I expect to be able to defend against outside of the solutions 
you mention, but those are not feasible on commodity consumer hardware. 
I'm looking to achieve the best we can with what we have. This is also 
not an attack I've heard of in the wild against consumer hardware; I 
know it's possible because I know people who've done it, but it takes 
many weeks (at least) of research and effort to prepare for a given chip 
- definitely not as easy as a cold-boot attack which can take seconds 
and works pretty universally.

> To address the whole set of problems, it might be that the answer
> might lie in something like confidential compute, where the all of the
> memory encrypted.  Now you don't need to worry about wiping the page
> cache, since it's all encrypted.  Of course, you still need to solve
> the problem of how to restablish the confidential compute keys after
> it has been wiped as part of the suspend, but you needed to solve that
> with the LUKS key anyway.

Without special hardware support you'll need to re-establish keys via 
unencrypted software, and unencrypted software can be replaced by an 
attacker if they're able to write to RAM. So it doesn't solve the 
problem you bring up. But anyway I feel this part of the discussion is 
starting to border on theoretical...

Though I suppose encrypting all the memory belonging to just the one 
user with that user's LUKS volume key could be an alternative solution. 
That way wiping out the key has the effect of "wiping out" all the 
user's related memory, at least until we can re-authenticate and bring 
it all back. But I suspect this would not only be extremely difficult to 
implement in the kernel but would also have huge performance cost 
without special hardware

> Anoter potential approach is a bit more targetted, which is to mark
> certain files as containing keying information, so the system can
> focus on making sure those pages are wiped at suspend time.  It still
> has issues, such as how the desire to wipe them from the memory at
> suspend time interacts with mlock(), which is often done by programs
> to prevent them from getting written to swap.  And of course, we still
> need to worry about what to do if the file is pinned because it's
> being accessed by RDMA or by sendfile(2) --- but perhaps a keyfile has
> no business of being accessed via RDMA or blasted out (unencrypted!)
> at high speed to a network connection via sendfile(2) --- and so
> perhaps those sorts of things should be disallowed if the file is
> marked as "this file contains secret keys --- treat it specially".

Secret keys are not what we're trying to protect here necessarily. 
Random user documents are often sensitive. People store tax documents, 
corporate secrets, or any number of other sensitive things on their 
computers. If an attacker can perform a cold boot attack on the device 
then depending on how recently these tax documents or corporate secrets 
were accessed they might just be in memory in plain text, which is not 
good. No amount of protecting the keys prevents this.

That said, having an extra security layer for secret keys would be 
useful. There are definitely files that contain sensitive data, and it 
would be useful to tell the kernel which files those are so that it can 
treat them extra carefully in the ways you suggest. Maybe even avoid 
putting them in plain text into the page cache? But this would have to 
be an extra step, since it's not feasible to make the user mark all the 
files that they consider to be sensitive

Adrian