Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAMBbDaF2Ni0gMRKNeFTQwgAOPPYy7RLXYwDJyZ1edq=tfATFzw@mail.gmail.com>
 <1D8F1768-D42A-4775-9B0E-B507D5F9E51E@oracle.com> <YxsGIoFlKkpQdSDY@mit.edu> <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
In-Reply-To: <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
From:   battery dude <jyf007@gmail.com>
Date:   Sat, 10 Sep 2022 17:15:11 -0500
Message-ID: <CAMBbDaFsFFowLWeiqUg-2O6Px2GjvA6La3dwzomw7Ps_0s2enA@mail.gmail.com>
Subject: Re: Does NFS support Linux Capabilities
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     "Theodore Ts'o" <tytso@mit.edu>,
        Chuck Lever III <chuck.lever@oracle.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>,
        "selinux@vger.kernel.org" <selinux@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

https://discourse.pi-hole.net/t/ftl-not-running-in-web-interface/10412?page=
=3D2
https://serverfault.com/questions/886804/non-root-user-needing-chown-capabi=
lity-on-nfs-client
other refer

Casey Schaufler <casey@schaufler-ca.com> =E4=BA=8E2022=E5=B9=B49=E6=9C=889=
=E6=97=A5=E5=91=A8=E4=BA=94 10:59=E5=86=99=E9=81=93=EF=BC=9A
>
> 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 capabiliti=
es.
> 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