Does NFS support Linux Capabilities

[battery dude]

https://discourse.pi-hole.net/t/ftl-not-running-in-web-interface/10412?page=2
https://serverfault.com/questions/886804/non-root-user-needing-chown-capability-on-nfs-client
other refer

Casey Schaufler <casey at schaufler-ca.com> 于2022年9月9日周五 10:59写道：
>
> On 9/9/2022 2:23 AM, Theodore Ts'o wrote:
> > On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
> >> I'm not sure how closely other implementations come to implementing
> >> POSIX.1e, but there are enough differences that interoperability
> >> could be a nightmare. ...
> > ...
> >> The NFSv4 WG could invent our own capabilities scheme, just as was
> >> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> >> was 100% successful.
> > Indeed, what the NFSv4 working group could do is to take a survey of
> > what capabilities are in use, and more importantly, how they are
> > defined, and create a superset of all of those capabilities and
> > publish it as an RFC.  The tricky bit might be there were multiple
> > versions of the Posix.1e that were published, and different Legacy
> > Unices shipped implementations conforming to different drafts of
> > Posix.1e as part of the ill-fated "C2 by '92" initiative.
> >
> > ...
> >
> > In any case, what this means is the exact details of what some
> > particular capability might control could differ from system to
> > system.  OTOH, I'm not sure how much that matters, since capability
> > masks are applied to binaries, and it's unlikely that it would matter
> > that a particular capabiity on an executable meant for Solaris 2.4SE
> > with C2 certification might be confusing to AIX 4.3.2 (released in
> > 1999; so much for C2 by '92) that supported Orange Book C2, since AIX
> > can't run Solaris binaries.  :-)
>
> Data General's UNIX system supported in excess of 330 capabilities.
> Linux is currently using 40. Linux has deviated substantially from
> the Withdrawn Draft, especially in the handling of effective capabilities.
> I believe that you could support POSIX capabilities or Linux capabilities,
> but an attempt to support both is impractical. Supporting any given
> UNIX implementation is possible, but once you get past the POSIX defined
> capabilities into the vendor specific ones interoperability ain't gonna
> happen.
>
> >> Given these enormous challenges, who would be willing to pay for
> >> standardization and implementation? I'm not saying it can't or
> >> shouldn't be done, just that it would be a mighty heavy lift.
> >> But maybe other folks on the Cc: list have ideas that could
> >> make this easier than I believe it to be.
> > .. and this is why the C2 by '92 initiative was doomed to failure,
> > and why Posix.1e never completed the standardization process.  :-)
>
> The POSIX.1e effort wasn't completed because vendors lost interest
> in the standards process and because they lost interest in the
> evaluated security process. That, and we'd made way too many trips
> to Poughkeepsie.
>
> > Honestly, capabilities are super coarse-grained, and I'm not sure they
> > are all that useful if we were create blank slate requirements for a
> > modern high-security system.  So I'm not convinced the costs are
> > sufficient to balance the benefits.
>
> Granularity was always a bone of contention in the working group.
> What's sad is that granularity wasn't the driving force behind capabilities.
> The important point was to separate privilege from UID 0. In the end
> I think we'd have been better off with one capability, CAP_PRIVILEGED,
> defined in the specification and a note saying that beyond that you were
> on your own.
>
> > If I was going to start from scratch, and if I only cared about Linux
> > systems that supported ext4 and/or f2fs, I'd design something where
> > executables would use fsverity, and then combine it with an eBPF MAC
> > policy[1] that would key off of some policy identifier embedded in the
> > PKCS7 signature block located in the executable's fsverity metadata.
> > (The fsverity signature would be applied by a secure build service, to
> > guarantee exact correspondence between the binary and a specific
> > version checked into source control, to protect against the insider
> > threat of an engineer sneaking some kind of un-peer-reviewed back door
> > into the binary.)  The policy identifier might be used to provide some
> > kind of MAC enforcement, perhaps using seccomp to enforce what system
> > calls and ioctls said executable would be allowed to execute, or some
> > other kind of MAC policy.
> >
> > [1] https://lwn.net/Articles/809645/
> >
> > Speaking totally hypothetically, of course.  A bunch of what I've
> > described above isn't upstream, or even implemented yet.  (Although if
> > someone's interest is piqued in implementing some of this, please
> > contact me off-line.)
> >
> >                                               - Ted