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
