Subject: [nfsv4] Status of RPCSEC_GSSv3

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 15:50:13 -0500

I believe the I-D is in reasonable shape.

TODO:

 - Privileges list requires review by people familiar with fine-grained
privilege ("capabilities", in Linux speak) facilities of operating systems
other than Solaris.

 - Additional references are required for MAC.

 - Plenty of review.

 - We might want an option where the label is added to the MIC sent in
opaque_auth, so that we don't need an RPCSEC_GSSv3 context for every label a
user uses -- this might be particularly important for SElinux.  Problem:
we're limited to 400 bytes in which to fit the label and the context handle
ID and MIC, and it's difficult to predict whether we can fit them all, but
when we can't we can always fallback on getting a new handle anyways, so I
think this is a non-problem.

 - Add text explicitly allowing simplified profiles.

Please review!

Also, I believe there are people who are implementing. Implementation
experience comments would be appreciated.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 16:00:10 -0500

On Apr 7, 2011, at 3:50 PM, Nico Williams wrote:

>  - Privileges list requires review by people familiar with fine-grained privilege ("capabilities", in Linux speak) facilities of operating systems other than Solaris.
> 
> 

Do we know who to ask to do the review or do we need to get someone to find out who to ask?

>  - We might want an option where the label is added to the MIC sent in opaque_auth, so that we don't need an RPCSEC_GSSv3 context for every label a user uses -- this might be particularly important for SElinux.  Problem: we're limited to 400 bytes in which to fit the label and the context handle ID and MIC, and it's difficult to predict whether we can fit them all, but when we can't we can always fallback on getting a new handle anyways, so I think this is a non-problem.
> 

I also want us to explore deprecating v2 and also to gather all of the XDR in one place.

Do we know if anyone has implemented v2 or is everyone doing v1?

The main driver for v2 appeared to be channel bindings. v3 introduces a simpler
channel binding approach more in line with industry practice.

> Please review!
> 
> Also, I believe there are people who are implementing. Implementation experience comments would be appreciated.
> 
> Nico
> --
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 17:06:42 -0500

> Do we know who to ask to do the review or do we need to get someone to find

Ideally we could get review of the privileges section from one or more
participants with expertise in Linux, *BSD, and Windows.

> I also want us to explore deprecating v2 and also to gather all of the XDR

+1.  But if deprecating v2 were to slow us down then I'd leave that
for some other time.

> The main driver for v2 appeared to be channel bindings. v3 introduces a
> simpler  channel binding approach more in line with industry practice.

Indeed!

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 18:07:14 -0500

One of the forwarded comments was about RPCSEC_GSS3_LABEL_PROBLEM and
the lack of a RPCSEC_GSS3_PRIV_PROBLEM status code.  This was my
answer:

Hmmm.  The thought occurs that having the server return an error when
it doesn't understand one of those things is not really a good idea.
The reason is that the client might want a handle no matter what, in
which case the client would have to go remove some assertion and try
again.  Ad naseum until it gets a handle.  Seems like a bad idea to
me.

Instead I think we want to add flag field to rpc_gss3_create_res to
indicate whether the server understood or failed to understand any of
the client's assertions.  Or maybe instead of just granted_assertions
we'll want to also add "assertions_not_understood" and
"assertions_not_granted".

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 18:37:12 -0500

> privilege ("capabilities", in Linux speak) facilities of operating systems

Evidently FreeBSD has something like this, but I can't find a list of
privileges.

Linux has very few capabilities related to filesystems operation, but
there are some, including some that Solaris doesn't have (CAP_FSETID
in particular): CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER,
CAP_FSETID.

| CAP_FSETID
|     Don't clear set-user-ID and set-group-ID bits when a file is
modified; permit setting of the set-group-ID bit for a file whose GID
does not match the file system or any of the supplementary GIDs of the
calling process.

Windows has some privileges that Solaris doesn't have equivalents of either:

 - Backup files and directories
 - Restore files and directories
 - Take ownership of files or other objects (which is different from file_chown)

I don't know if the backup/restore privileges are relevant to NFSv4.

So I see only two privileges to add to section 3 of the I-D:

 - priv_setid_no_reset (don't reset set-id bits on write)
 - priv_chown_to_self (take ownership -- lesser than priv_chown and
different from priv_chown_self)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 18:48:20 -0500

I found a paper from 2000 about the privilege model of TrustedBSD.  In
there I found some additional privileges I hadn't listed, particularly
related to overriding MAC policy:

cap_mac_downgrade
cap_mac_read (missing in my I-D)
cap_mac_upgrade
cap_mac_write (missing in my I-D)

Also, the capability for preventing set-id bit reset on write is split
into two, one for set-user and one for set-group.

That paper may be out of date!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 19:24:54 -0500

> the lack of a RPCSEC_GSS3_PRIV_PROBLEM status code.  This was my

OK, I'm convinced to add some things to the response.  The PROBLEM
codes should probably be dropped, except that some servers might
consider some problems with the client's assertions to be fatal
(though I'm not sure why!).  Attached is the new .x, with all other
issues corrected.

Nico
--

---

From: Dave Quigley <[email-masked]>
Date: Mon, 11 Apr 2011 22:25:26 -0400

On 4/7/2011 6:06 PM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 4:00 PM, Thomas Haynes<[email-masked]>  wrote:

A good person to ask about the Linux privileges/capabilities would be 
Serge Hallyn as he is the main person pushing capabilities in Linux. I 
will send him an email explaining the situation. Should I CC the list 
when I do? or should I ask him to participate on list and point him to 
this discussion?