Re: Does NFS support Linux Capabilities

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 [off-list ref] 于2022年9月9日周五 10:59写道：

On 9/9/2022 2:23 AM, Theodore Ts'o wrote:

quoted

On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:

quoted

I'm not sure how closely other implementations come to implementing
POSIX.1e, but there are enough differences that interoperability
could be a nightmare. ...

...

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

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