linux-kernel - Re: [PATCH 0/4] exportfs: add flag to allow marking export operations as only supporting file handles

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: <CAOQ4uxgzWZ_X8S6dnWSwU=o5QKR_azq=5fe2Qw8gavLuTOy7Aw@mail.gmail.com>
Date: Sat, 7 Dec 2024 09:49:02 +0100
From: Amir Goldstein <amir73il@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, Christian Brauner <brauner@...nel.org>, 
	Jeff Layton <jlayton@...nel.org>, Erin Shepherd <erin.shepherd@....eu>, 
	Chuck Lever <chuck.lever@...cle.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	stable <stable@...nel.org>
Subject: Re: [PATCH 0/4] exportfs: add flag to allow marking export operations
 as only supporting file handles

On Fri, Dec 6, 2024 at 5:03 PM Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Thu, Dec 05, 2024 at 12:57:28PM +0100, Amir Goldstein wrote:
> > On Thu, Dec 5, 2024 at 1:38 AM Christoph Hellwig <hch@...radead.org> wrote:
> > >
> > > On Sun, Dec 01, 2024 at 02:12:24PM +0100, Christian Brauner wrote:
> > > > Hey,
> > > >
> > > > Some filesystems like kernfs and pidfs support file handles as a
> > > > convenience to enable the use of name_to_handle_at(2) and
> > > > open_by_handle_at(2) but don't want to and cannot be reliably exported.
> > > > Add a flag that allows them to mark their export operations accordingly
> > > > and make NFS check for its presence.
> > > >
> > > > @Amir, I'll reorder the patches such that this series comes prior to the
> > > > pidfs file handle series. Doing it that way will mean that there's never
> > > > a state where pidfs supports file handles while also being exportable.
> > > > It's probably not a big deal but it's definitely cleaner. It also means
> > > > the last patch in this series to mark pidfs as non-exportable can be
> > > > dropped. Instead pidfs export operations will be marked as
> > > > non-exportable in the patch that they are added in.
> > >
> > > Can you please invert the polarity?  Marking something as not supporting
> > > is always awkward.  Clearly marking it as supporting something (and
> > > writing down in detail what is required for that) is much better, even
> > > it might cause a little more churn initially.
> > >
> >
> > Churn would be a bit annoying, but I guess it makes sense.
> > I agree with Christian that it should be done as cleanup to allow for
> > easier backport.
> >
> > Please suggest a name for this opt-in flag.
> > EXPORT_OP_NFS_EXPORT???
>
> That's probably too specific to NFS--
>
> AFAICT the goal here is to prevent exporting {pid,kern}fs file handles
> to other nodes, correct?  Because we don't want to allow a process on
> another computer to mess around with processes on the local computer?
>
> How about:
>
> /* file handles can be used by a process on another node */
> #define EXPORT_OP_ALLOW_REMOTE_NODES    (...)

This has a sound of security which is incorrect IMO.
The fact that we block nfsd export of cgroups does not prevent
any type of userland file server from exporting cgroup file handles.

I hate to be a pain, but IMO, the claim that inverted polarity is clearer
is not a consensus and there are plenty of counter examples.
I do not object to inverting the polarity if a flag name is found
that explains the property well, but IMO, this is not it.

Maybe opt-out of nfsd export is a little less safer than opt-in, but
1. opt-out is and will remain the rare exception for export_operations
2. at least the flag name EXPORT_OP_LOCAL_FILE_HANDLE
    is pretty clear IMO

Plus, as I wrote in another email, the fact that pidfs is SB_NOUSER,
so userspace is not allowed to mount it into the namespace and
userland file servers cannot export the filesystem itself.
That property itself (SB_NOUSER), is therefore a good enough indication
to deny nfsd export of this fs.
So really the immediate need for an explicit flag is only to stop exporting
kernfs/cgroupfs and I don't see this need spreading much further
(perhaps to nsfs) and therefore, the value of inverting to opt-in is
questionable IMO.

Thanks,
Amir.