linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Sun, 11 Sep 2022 06:00:41 -0400	[thread overview]
Message-ID: <Yx2xyW5n0ECZX9bJ@mit.edu> (raw)
In-Reply-To: <8865e109-3ec6-f848-8014-9fe58e3876f4@schaufler-ca.com>

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

  parent reply	other threads:[~2022-09-11 14:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMBbDaF2Ni0gMRKNeFTQwgAOPPYy7RLXYwDJyZ1edq=tfATFzw@mail.gmail.com>
2022-09-08 20:24 ` Does NFS support Linux Capabilities Chuck Lever III
2022-09-08 21:03   ` Jeff Layton
2022-09-08 21:17     ` Chuck Lever III
2022-09-08 21:28       ` Jeff Layton
     [not found]         ` <CAMBbDaEYWfcuf0bZkCFxaK=9zFVCuvMn1rtHcoP+axcF6BGtcA@mail.gmail.com>
2022-09-08 22:21           ` Jeff Layton
2022-09-09  9:23   ` Theodore Ts'o
2022-09-09 13:13     ` J. Bruce Fields
2022-09-09 14:53       ` Chuck Lever III
2022-09-09 15:59     ` Casey Schaufler
2022-09-10 22:15       ` battery dude
2022-09-11 10:00       ` Theodore Ts'o [this message]
2022-09-12  4:03         ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yx2xyW5n0ECZX9bJ@mit.edu \
    --to=tytso@mit.edu \
    --cc=casey@schaufler-ca.com \
    --cc=chuck.lever@oracle.com \
    --cc=jyf007@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).