From: "Theodore Tso" <tytso@mit.edu>
To: Nathan Royce <nroycea+kernel@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>
Subject: Re: TmpFs Incorporation Of FsCrypt?
Date: Wed, 14 Jan 2026 12:43:52 -0800 [thread overview]
Message-ID: <20260114204352.GA19200@macsyma.local> (raw)
In-Reply-To: <CALaQ_ho-dx9CTee_-R1VFreX=jB3Zbdjo68fdnnwC1cPoPcjVg@mail.gmail.com>
On Wed, Jan 14, 2026 at 01:03:20AM -0600, Nathan Royce wrote:
> But I also saw: `The source files are located on an in-memory filesystem
> such as tmpfs.` in the main README, which makes me wonder if there is
> intent/plan to bring fscrypt to tmpfs.
>
> I'm kind of thinking a use case of having keys and/or a password manager
> database on external/encrypted storage, that gets transferred to some
> random path in `/run/user/<#>` (tmpfs) on login where it is encrypted as
> well (then the storage is unmounted/locked/removed), and the respective
> program that uses the file(s) would point to a freshly generated config
> that points to the random location.
I'm not aware of anyone considering adding fscrypt to tmpfs. One
reason why it might not make sense is that the primary value that
fscrypt add is encryption at rest. For example, if you are using
fscrypt to protect user files on a mobile phone, the file system level
encryption protects the data from being accessible immediately after
the phone is rebooted or power cycled. Many of the attacks which
require direct access to the flash storage, or attempts to replace the
kernel with one special "enhancements" courtesy of the NSA, KGB,
Mossad, or MSS.
However, if there is a zero day vulnerability which allows the
attacker to compromise the currently running kernel without requiring
a reboot, and while the encryption keys are in memory because the user
is logged in --- fscrypt will likely not provide much protection.
That's because if the keys are loaded, and the decrypted file contents
are in the page cache, the only thing that prevents the attacker from
gaining access to the file contents is the Unix permissions, and the
system's discretionary access controls are very likely going to be
compromised if the kernel has been compromised.
This is why fscrypt for tmpfs might not be that useful. Tmpfs is not
applicable for storage at rest. So when you copy the encrypted files
from the persistent storage to the tmpfs, if you use fscrypt with
tmpfs, the only way it would add value is if you want to remove the
encryption keys from memory, without actually deleting the files from
tmpfs. Otherwise, why not just zero the files and deleting the files
from tmpfs, and when the user logs back in, just copy the files from
the persistent storage into tmpfs?
Cheers,
- Ted
next prev parent reply other threads:[~2026-01-14 20:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 7:03 Nathan Royce
2026-01-14 20:43 ` Theodore Tso [this message]
2026-01-14 23:32 ` Nathan Royce
2026-01-14 7:25 Nathan Royce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260114204352.GA19200@macsyma.local \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nroycea+kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox