https://discourse.pi-hole.net/t/ftl-not-running-in-web-interface/10412?page=2 https://serverfault.com/questions/886804/non-root-user-needing-chown-capability-on-nfs-client other refer Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 于2022年9月9日周五 10:59写道： > > On 9/9/2022 2:23 AM, Theodore Ts'o wrote: > > 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. ... > > ... > >> 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. > > > > ... > > > > 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. :-) > > Data General's UNIX system supported in excess of 330 capabilities. > Linux is currently using 40. Linux has deviated substantially from > the Withdrawn Draft, especially in the handling of effective capabilities. > I believe that you could support POSIX capabilities or Linux capabilities, > but an attempt to support both is impractical. Supporting any given > UNIX implementation is possible, but once you get past the POSIX defined > capabilities into the vendor specific ones interoperability ain't gonna > happen. > > >> 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. :-) > > The POSIX.1e effort wasn't completed because vendors lost interest > in the standards process and because they lost interest in the > evaluated security process. That, and we'd made way too many trips > to Poughkeepsie. > > > 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. > > Granularity was always a bone of contention in the working group. > What's sad is that granularity wasn't the driving force behind capabilities. > The important point was to separate privilege from UID 0. In the end > I think we'd have been better off with one capability, CAP_PRIVILEGED, > defined in the specification and a note saying that beyond that you were > on your own. > > > 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
