TmpFs Incorporation Of FsCrypt?

TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

I recently saw the PRs for BTRFS relating to FSCRYPT, and thought I'd
explore the fscrypt package.

I started with `status` before moving to `setup` on the `/tmp` path which
is tmpfs.
As expected I'm sure, I got: `[ERROR] fscrypt setup: filesystem type tmpfs
is not supported for fscrypt setup`

Looking in https://github.com/google/fscrypt, I saw:
https://github.com/google/fscrypt/blob/ea916da7fa9844cc3da608e75510f478c7b09f7d/cli-tests/t_not_supported.sh
which coincides with my presumably expected error.

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.

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: TmpFs Incorporation Of FsCrypt?

[Theodore Tso]

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

Re: TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

Yeah, I believe I had read that once root has been compromised, it's
game-over. They'd have access to the entire keyring for all sessions.
I think I also understand that if one were to counter kernel
corruption attempts, signed kernels, using a BL key, would be the way
to go.

What I like about fscrypt is it does appear to be session-based, so
compared to LUKS, which just needs a key once to unlock it for
everyone, fscrypt looks like it remains encrypted for everyone except
the user that unlocked the path for that session.
So if a user account maybe shares a path within their user path, with
another user/group, a misconfiguration would supposedly keep an
encrypted path still encrypted to the other shared user, even if the
originating user has it unlocked for themselves.

It was just a mere curiosity, and sounds like I got my answer. I'm
really anxious for BTRFS to implement it, as I expect I may transition
to fscrypt from luks. I'm just not really seeing the issue with not
having metadata encrypted. My view may flip-flop as I try it. I could
always use both I guess, though luks would be limited to 32 key slots.

On Wed, Jan 14, 2026 at 2:43 PM Theodore Tso <tytso@mit.edu> wrote:
> 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
>

Re: TmpFs Incorporation Of FsCrypt?

[Theodore Tso]

On Wed, Jan 14, 2026 at 05:32:22PM -0600, Nathan Royce wrote:
> What I like about fscrypt is it does appear to be session-based, so
> compared to LUKS, which just needs a key once to unlock it for
> everyone, fscrypt looks like it remains encrypted for everyone except
> the user that unlocked the path for that session.
> So if a user account maybe shares a path within their user path, with
> another user/group, a misconfiguration would supposedly keep an
> encrypted path still encrypted to the other shared user, even if the
> originating user has it unlocked for themselves.

Actually, no it doesn't work that way.  Access to the fscrypt key is
on based on the keyring, which is session based.  However, that key is
used to derive the per-file encryption key.  Once that key is
available, it's stashed in the in-memory inode structure --- and if
the file's unix permissions is world-readable, anyone will have access
to the file.

When the user logs out and the key is removed, we will iterate over
zap all of the encrypted inodes and dentries; see do_remove_key() and
try_to_lock_encrypted_keys() in fs/crypto/keyring.c.  So if you have a
ChromeOS device which is shared across multiple users in a family,
when Alice logs out of the ChromeOS laptop, and her brother Bob logs
into the laptop, this is the mechanism that prevents Bob from being
able to access Alice's files, even if Bob has a zero-day exploit,
given that Alice's master key is only available when Alice has
presented her password to the system, Bob won't be able to read's
Alice's secret dairy.

The main advantage of fscrypt and LUKS is that we can have separate
master keys for Alice and Bob, as opposed to having a single for the
entire dmcrypt device, as in the case for LUKS.  The other advantage
of fscrypt is that Alice and Bob can share the free space --- and
indeed, if Bob is logged into a ChromeOS device, and the free space is
almost exhausted (since if you have a very low-cost ChromeOS device
with only 32GB of flash, we can still reasonably share this device
across multiple users, since most of the user's data is stored in the
Cloud), what a root process can do is to find other users' Chrome
cache directories (e.g., such as Alice), and while the root process
which is managing ChromeOS's storage space, won't have access to
Alice's file contents, what the space management daemon *can* do is
delete the oldest files from directory that happens to be Alice's
cache directory, thus making space for Bob to cache more files in his
home directory.  Of course, then when Bob logs out, his cache files
might be subject for deletion when Alice starts using the machine,
even though Alice and Bob won't have access to their siblings' file
data.

Cheers,

					- Ted

Re: TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

On Wed, Jan 14, 2026 at 8:59 PM Theodore Tso <tytso@mit.edu> wrote:
> Actually, no it doesn't work that way.  Access to the fscrypt key is
> on based on the keyring, which is session based.  However, that key is
> used to derive the per-file encryption key.  Once that key is
> available, it's stashed in the in-memory inode structure --- and if
> the file's unix permissions is world-readable, anyone will have access
> to the file.
>
> When the user logs out and the key is removed, we will iterate over
> zap all of the encrypted inodes and dentries; see do_remove_key() and
> try_to_lock_encrypted_keys() in fs/crypto/keyring.c.  So if you have a
> ChromeOS device which is shared across multiple users in a family,
> when Alice logs out of the ChromeOS laptop, and her brother Bob logs
> into the laptop, this is the mechanism that prevents Bob from being
> able to access Alice's files, even if Bob has a zero-day exploit,
> given that Alice's master key is only available when Alice has
> presented her password to the system, Bob won't be able to read's
> Alice's secret dairy.
>
> The main advantage of fscrypt and LUKS is that we can have separate
> master keys for Alice and Bob, as opposed to having a single for the
> entire dmcrypt device, as in the case for LUKS.  The other advantage
> of fscrypt is that Alice and Bob can share the free space --- and
> indeed, if Bob is logged into a ChromeOS device, and the free space is
> almost exhausted (since if you have a very low-cost ChromeOS device
> with only 32GB of flash, we can still reasonably share this device
> across multiple users, since most of the user's data is stored in the
> Cloud), what a root process can do is to find other users' Chrome
> cache directories (e.g., such as Alice), and while the root process
> which is managing ChromeOS's storage space, won't have access to
> Alice's file contents, what the space management daemon *can* do is
> delete the oldest files from directory that happens to be Alice's
> cache directory, thus making space for Bob to cache more files in his
> home directory.  Of course, then when Bob logs out, his cache files
> might be subject for deletion when Alice starts using the machine,
> even though Alice and Bob won't have access to their siblings' file
> data.

Ugh, okay. Thanks for that insight...
This is the flip-flopping that I'm talking about for myself, because
if it worked the way I was hoping, that was the real draw for me.
I just figured the inode structure might/could also be session-based,
or a mix of global/session.
I was surprised when you mentioned the ability to reclaim space from
encrypted cache, and went to look into it, and came across
https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data/
(even though it's ecryptfs).
It makes sense, and is a valid good reason for keeping fscrypt into
consideration over doing something like `homed` luks/btrfs loopback
file.
Thanks again for setting me straight with my misconception.

Re: TmpFs Incorporation Of FsCrypt?

[Theodore Tso]

On Thu, Jan 15, 2026 at 01:04:48AM -0600, Nathan Royce wrote:
> This is the flip-flopping that I'm talking about for myself, because
> if it worked the way I was hoping, that was the real draw for me.
> I just figured the inode structure might/could also be session-based,
> or a mix of global/session.

The assumption is that these use cases (ChromeOS, Android) were ones
where only one user would be using the device at a time.  Adding
per-session keying would have been extra complexity and a performance
gain for not a whole lot of benefit.  It's much simpler to just wipe
the page cache and encryption keys when the user logs out, since the
primary goal was preventing off-line ("evil maid") attacks and
zero-day security vulnerabilities.  

> I was surprised when you mentioned the ability to reclaim space from
> encrypted cache, and went to look into it, and came across
> https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data/
> (even though it's ecryptfs).
> It makes sense, and is a valid good reason for keeping fscrypt into
> consideration over doing something like `homed` luks/btrfs loopback
> file.

fscrypt was designed as a solution to avoid the races that allowed
programs like fsstress to quickly and reliably cause system deadlocks,
as was the case with ecryptfs.

In the case where you don't need the multi-user keying, the ability to
share free space, and the ability for root to delete files when the
key is not loaded to manage the shared free spacee, LUKS is the
preferred solution because it encrypts the metadata.  fscrypt leaks
things like the timestamps and file size, and there are ways that an
attacker can use this to figure out things about how the system is
used.

For example, consider what might happen if the Chinese government
created a fake "free tibet" website, and embedded the web page a
half-dozen hidden image files of specific sizes.  Now when you cross
the border, and they seize your laptop, if encrypted files of those
specific sizes appear in your home directory, that might be a strong
signal that you had visited that particular web site.

Like many things, it's all about engineering tradeoffs, and there are
reasons why some solutions might be a better fit than others.  There
is rarely a one-size-fits-all solution.

Cheers,

							- Ted

TmpFs Incorporation Of FsCrypt?

[Nathan Royce]

I recently saw the PRs for BTRFS relating to FSCRYPT, and thought I'd
explore the fscrypt package.

I started with `status` before moving to `setup` on the `/tmp` path
which is tmpfs.
As expected I'm sure, I got: `[ERROR] fscrypt setup: filesystem type
tmpfs is not supported for fscrypt setup`

Looking in https://github.com/google/fscrypt, I saw:
https://github.com/google/fscrypt/blob/ea916da7fa9844cc3da608e75510f478c7b09f7d/cli-tests/t_not_supported.sh
which coincides with my presumably expected error.

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.