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: <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>
Date:   Fri, 9 Sep 2022 08:59:41 -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>,
        Chuck Lever III <chuck.lever@oracle.com>
Cc:     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>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <YxsGIoFlKkpQdSDY@mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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