> On Sep 8, 2022, at 5:03 PM, Jeff Layton <jlayton@xxxxxxxxxx> 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@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. >> >> > > 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
