Does NFS support Linux Capabilities

[Chuck Lever III]

> On Sep 8, 2022, at 5:03 PM, Jeff Layton <jlayton at kernel.org> wrote:
> 
> On Thu, 2022-09-08 at 20:24 +0000, Chuck Lever III wrote:
>> [ 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.
>> 
>> 
> 
> I'm not disputing anything you wrote above, and I clearly haven't
> thought through the security implications, but I wonder if we could
> piggyback this info onto security label support somehow? That already
> requires a (semi-opaque) per-inode attribute, which is mostly what's
> required for file capabilities.

That was the starting idea for accessing IMA metadata on NFS until
we discovered that NFSv4 security labels are intended to enable only
a single label per file. Capabilities are often present with SELinux
labels.

It would work for a proof of concept, though.


--
Chuck Lever