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
