[ 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@xxxxxxxxx> 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
