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;
Date:   Sun, 11 Sep 2022 06:00:41 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     Chuck Lever III <chuck.lever@oracle.com>,
        battery dude <jyf007@gmail.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>
Subject: Re: Does NFS support Linux Capabilities
Message-ID: <Yx2xyW5n0ECZX9bJ@mit.edu>
References: <CAMBbDaF2Ni0gMRKNeFTQwgAOPPYy7RLXYwDJyZ1edq=tfATFzw@mail.gmail.com>
 <1D8F1768-D42A-4775-9B0E-B507D5F9E51E@oracle.com>
 <YxsGIoFlKkpQdSDY@mit.edu>
 <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
Precedence: bulk

On Fri, Sep 09, 2022 at 08:59:41AM -0700, Casey Schaufler wrote:
> 
> 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.

Yeah, good point, I had forgotten about how we (Linux) ended up
diverging from POSIX 1.e when we changed how effective capabilities
were calculated.

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

And from an NFS perspective, if we had (for example) a Trusted Solaris
trying to emulate Linux binaries over NFS with capabilities masks, I
suspect trying to map Linux's Capabilities onto Trusted Solaris's
implementation of POSIX 1.e would be the least of Oracle's technical
challenges.  :-)

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

It was my sense was that the reason why they lost interested in the
evaluated security process was simply that the business case didn't
make any sense.  That is, the $$$ they might get from US Government
sales was probability not worth the opportunity cost of the engineers
tasked to work on Trusted {AIX,DG,HPUX,Solaris}.  Heck, I'm not sure
the revenue would balance out the _costs_, let alone the opportunity
costs...

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

Well, hey, we almost have that already, sort of --- CAP_SYS_ADMIN ==
"root", for almost all intents and purposes.  :-)

						- Ted