Re: [PATCH v1 0/4] kNFSD Signed Filehandles

[Trond Myklebust <trondmy@kernel.org>]

On Fri, 2026-01-16 at 14:43 -0500, Chuck Lever wrote:
> On 1/16/26 12:17 PM, Benjamin Coddington wrote:
> > On 16 Jan 2026, at 11:56, Chuck Lever wrote:
> > 
> > > On Fri, Jan 16, 2026, at 9:32 AM, Benjamin Coddington wrote:
> > > > The following series enables the linux NFS server to add a
> > > > Message
> > > > Authentication Code (MAC) to the filehandles it gives to
> > > > clients.  This
> > > > provides additional protection to the exported filesystem
> > > > against filehandle
> > > > guessing attacks.
> > > > 
> > > > Filesystems generate their own filehandles through the
> > > > export_operation
> > > > "encode_fh" and a filehandle provides sufficient access to open
> > > > a file
> > > > without needing to perform a lookup.  An NFS client holding a
> > > > valid
> > > > filehandle can remotely open and read the contents of the file
> > > > referred to
> > > > by the filehandle.
> > > 
> > > "open, read, or modify the contents of the file"
> > > 
> > > Btw, referring to "open" here is a little confusing, since NFSv3
> > > does
> > > not have an on-the-wire OPEN operation. I'm not sure how to
> > > clarify.
> > > 
> > > 
> > > > In order to acquire a filehandle, you must perform lookup
> > > > operations on the
> > > > parent directory(ies), and the permissions on those directories
> > > > may
> > > > prohibit you from walking into them to find the files within. 
> > > > This would
> > > > normally be considered sufficient protection on a local
> > > > filesystem to
> > > > prohibit users from accessing those files, however when the
> > > > filesystem is
> > > > exported via NFS those files can still be accessed by guessing
> > > > the correct,
> > > > valid filehandles.
> > > 
> > > Instead: "an exported file can be accessed whenever the NFS
> > > server is
> > > presented with the correct filehandle, which can be guessed or
> > > acquired
> > > by means other than LOOKUP."
> > > 
> > > 
> > > > Filehandles are easy to guess because they are well-formed. 
> > > > The
> > > > open_by_handle_at(2) man page contains an example C program
> > > > (t_name_to_handle_at.c) that can display a filehandle given a
> > > > path.  Here's
> > > > an example filehandle from a fairly modern XFS:
> > > > 
> > > > # ./t_name_to_handle_at /exports/foo
> > > > 57
> > > > 12 129    99 00 00 00 00 00 00 00 b4 10 0b 8c
> > > > 
> > > >           ^---------  filehandle  ----------^
> > > >           ^------- inode -------^ ^-- gen --^
> > > > 
> > > > This filehandle consists of a 64-bit inode number and 32-bit
> > > > generation
> > > > number.  Because the handle is well-formed, its easy to
> > > > fabricate
> > > > filehandles that match other files within the same filesystem. 
> > > > You can
> > > > simply insert inode numbers and iterate on the generation
> > > > number.
> > > > Eventually you'll be able to access the file using
> > > > open_by_handle_at(2).
> > > > For a local system, open_by_handle_at(2) requires
> > > > CAP_DAC_READ_SEARCH, which
> > > > protects against guessing attacks by unprivileged users.
> > > > 
> > > > In contrast to a local user using open_by_handle(2), the NFS
> > > > server must
> > > > permissively allow remote clients to open by filehandle without
> > > > being able
> > > > to check or trust the remote caller's access.
> 
> Btw, "allow ... clients to open by filehandle" is another confusion.
> 
> NFSv4 OPEN does do access checking and authorization.
> 
> Again, it's NFS READ and WRITE that are not blocked.
> 
> NFSv3 READ and WRITE do an intrinsic open.
> 
> NFSv4 READ and WRITE permit the use of a special stateid so that an
> OPEN
> isn't necessary to do the I/O (IIRC).
> 
> 
> > > > Therefore additional
> > > > protection against this attack is needed for NFS case.  We
> > > > propose to sign
> > > > filehandles by appending an 8-byte MAC which is the siphash of
> > > > the
> > > > filehandle from a key set from the nfs-utilities.  NFS server
> > > > can then
> > > > ensure that guessing a valid filehandle+MAC is practically
> > > > impossible
> > > > without knowledge of the MAC's key.  The NFS server performs
> > > > optional
> > > > signing by possessing a key set from userspace and having the
> > > > "sign_fh"
> > > > export option.
> > > 
> > > OK, I guess this is where I got the idea this would be an export
> > > option.
> > > 
> > > But I'm unconvinced that this provides any real security. There
> > > are
> > > other ways of obtaining a filehandle besides guessing, and
> > > nothing
> > > here suggests that guessing is the premier attack methodology.
> > 
> > Help me understand you - you're unconvinced that having the server
> > sign
> > filehandles and verify filehandles prevents clients from
> > fabricating valid
> > ones?
> 
> The rationale provided here doesn't convince me that fabrication is
> the
> biggest threat and will give us the biggest bang for our buck if it
> is
> mitigated.
> 
> In order to carry out this attack, the attacker has to have access to
> the filehandles on an NFS client to examine them. She has to have
> access to a valid client IP address to send NFS requests from. Maybe
> you can bridge the gap by explaining how a /non-root/ user on an NFS
> client might leverage FH fabrication to gain access to another user's
> files. I think only the root user has this ability.
> 
> I've also tried to convince myself that cryptographic FH validation
> could mitigate misdirected WRITEs or READs. An attacker could replace
> the FH in a valid NFS request, for example, or a client might send
> garbage in an FH. I'm not sure those are real problems, though.
> 
> I am keeping in mind that everything here is using AUTH_SYS anyway,
> so
> maybe I'm just an old man yelling at a cloud. Nothing here is
> blocking
> yet, but I want the feature to provide meaningful value (as I think
> you
> do).
> 
> Thank you for bearing with me.
> 

Yes, there may be a root squash option that prevents synthesis of root
credentials, but that's not necessarily an impediment:

We assume that the attacker does have access to a userspace NFS client
on the authorised client and that they can synthesize calls.
If so, then GETATTR is unprivileged and will happily give up knowledge
of which owner/group combination to synthesize in an OPEN, READ or
WRITE call.


-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com