Does NFS support Linux Capabilities

[Theodore Ts'o]

On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
> 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!)

I'm not a lawyer and I don't play one on TV; I haven't even stayed at
a Holiday Inn recently.  :-)

However... please note that at least in the US, copyright does not
extend to *interfaces*.  This is why we can replicate interfaces such
as openat(2), which first appeared in Solaris, not to mention things
like the read(2) system call and the options to fsck, which first
appared in Unix systems encumbered by the AT&T Copyright license.

(And some of these licenses even had AT&T's claim that Unix "methods
and concepts" were trade secrets, although MIT had always refused to
sign any such license agreements, since they didn't want to encumber
the brains of their undergraduates.  So I've looked at BSD source code
as an MIT undergraduate without any kind of "Methods and Concepts"
taint, although trying to claim that the Unix methods and concepts are
a "trade secret" are kind of laughable at this point.  :-)

> 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.

(The US government was trying to get all Unix systems to have the
minimal Orange Book certification so the US Military could use them in
classified systems, and they hadn't figured out that US procurements
for the computer industry had transitioned from being the body of the
dog to being the tail.  For more details, see Steve Lipner's "The
Birth and Death of the Orange Book" published in the IEEE Annals of
the History of Computing, 2015.)

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.  :-)

> 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.  :-)

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.

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