linux-kernel - Re: TmpFs Incorporation Of FsCrypt?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALaQ_hq==FY64FcLedWnpgOXf_aT9g2eNyM6BgWwvTv8r0FR7w@mail.gmail.com>
Date: Wed, 14 Jan 2026 17:32:22 -0600
From: Nathan Royce <nroycea+kernel@...il.com>
To: Theodore Tso <tytso@....edu>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Hugh Dickins <hughd@...gle.com>
Subject: Re: TmpFs Incorporation Of FsCrypt?

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@....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
>