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;
Message-ID: <ee70a6bf-898c-63aa-c513-6c2f0f307f2b@schaufler-ca.com>
Date:   Sun, 11 Sep 2022 21:03:55 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Does NFS support Linux Capabilities
Content-Language: en-US
To:     Theodore Ts'o <tytso@mit.edu>
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>,
        casey@schaufler-ca.com
References: <CAMBbDaF2Ni0gMRKNeFTQwgAOPPYy7RLXYwDJyZ1edq=tfATFzw@mail.gmail.com>
 <1D8F1768-D42A-4775-9B0E-B507D5F9E51E@oracle.com> <YxsGIoFlKkpQdSDY@mit.edu>
 <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
 <Yx2xyW5n0ECZX9bJ@mit.edu>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <Yx2xyW5n0ECZX9bJ@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/11/2022 3:00 AM, Theodore Ts'o wrote:
> 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...

A B1 evaluation cost the vendor $1M/year for 3 years. At the time we were
selling large systems for $10M-20M, so you didn't have to sell very many
to justify the expense. Alas, salesmanship beats technological leadership
more often than you'd hope.

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

My, but did we have trouble teaching evaluators about CAP_SYS_ADMIN.
They had a very hard time understanding why we had to have a capability
for things that had nothing to do with the system security policy.
The problem is that including what CAP_SYS_ADMIN does in a "real"
security policy introduces an level of complexity that makes any kind
of analysis impractical. How does the ioctl() that reverses the spin
on a disk drive relate to DAC or MAC? What are the objects involved?

The big issue is that so few Linux kernel developers understand what
the Linux security policy is. So much emphasis has gone into "least
privilege" and "fine granularity" that it is rare to find someone who
is willing to think about the big picture.

> 						- Ted