Re: TmpFs Incorporation Of FsCrypt?

[Nathan Royce <nroycea+kernel@gmail.com>]

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
>