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
>

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.