Does NFS support Linux Capabilities

[Chuck Lever III]

[ This question comes up on occasion, so I've added a few interested
  parties to the Cc: list ]

> On Sep 8, 2022, at 8:27 AM, battery dude <jyf007 at gmail.com> wrote:
> 
> According to https://access.redhat.com/solutions/2117321 this article,
> I want to ask, how to make NFS support the penetration of Linux
> Capabilities

That link is access-limited, so I was able to view only the top
few paragraphs of it. Not very open, Red Hat.

TL;DR: I looked into this while trying to figure out how to enable
IMA on NFS files. It's difficult for many reasons.


A few of these reasons include:

The NFS protocol is a standard, and is implemented on a wide variety
of OS platforms. Each OS implements its own flavor of capabilities.
There's no way to translate amongst the variations to ensure
interoperation. On Linux, capabilities(7) says:

> No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.

I'm not sure how closely other implementations come to implementing
POSIX.1e, but there are enough differences that interoperability
could be a nightmare. Anything Linux has done differently than
POSIX.1e would be encumbered by GPL, making it nearly impossible to
standardize those differences. (Let alone the possible problems
trying to cite a withdrawn POSIX standard in an Internet RFC!)

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.


Currently, an NFS server bases its access control choices on the
RPC user that makes each request. We'd have to figure out a way to
enable NFS clients and servers to communicate more than just user
identity to enable access control via capabilities.

When sending an NFS request, a client would have to provide a set
of capabilities to the server so the server can make appropriate
access control choices for that request.

The server would have to report the updated capset when a client
accesses and executes a file with capabilities, and the server
would have to trust that its clients all respect those capsets
correctly.


Because capabilities are security-related, setting and retrieving
capabilities should be done only over networks that ensure
integrity of communication. So, protection via RPC-with-TLS or
RPCSEC GSS with an integrity service ought to be a requirement
both for setting and updating capabilities and for transmitting
any protected file content. We have implementations, but there
is always an option of not deploying this kind of protection
when NFS is actually in use, making capabilities just a bit of
security theater in those cases.


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.


--
Chuck Lever