Subject: Re: What credentials should a setuid process use after fork (was Re: [nfsv4] Client state security and the SSV)

From: Mike Eisler <[email-masked]>
Date: Mon, 21 May 2007 12:10:03 -0700 (PDT)

--- Mike Eisler <[email-masked]> wrote:

> In thinking about this more, while I disagree with the 
> assertion that Fred should be allowed to CLOSE Harry's files, even
> if Harry or Harry's client disagrees, I also see value in
> Rick's insight that the machine cred that created the client ID
> via EXCHANGE_ID should be allowed to CLOSE the Harry's files.
> The one trouble with that is that in a multi-user machine with
> no machine creds, Fred might have been the one that issued the
> EXCHANGE_ID.
> 
> So I'm thinking that we need a way to involve the SSV in
> protecting CLOSE, LOCKU, etc. to allow the client to
> tear down state of users that have expired creds.
> 
> A new GSS mechanism that uses the SSV as an RPCSEC_GSS
> authenticator is obviously one way to do it, but
> I don't believe in new mechanisms any more. I'll think on it
> more.

After some thinking and discussion with Dave Noveck, I've
got 2 approaches to offer:

(1) Change the inputs SET_SSV uses for verifying the digest 
    on input and the new digest on output to be the concatenated 
    of the XDR encoding of every op in the COMPOUND except the 
    SET_SSV. 

    The idea is if a client has no GSS creds, he can wrap
    issue COMPOUNDs with AUTH_NONE authentication,
    with a SET_SSV operation in them that include other
    operations besides SEQUENCE, such as LOCKU, CLOSE. 
    The use of SET_SSV protects
    the entire COMPOUND. Because SET_SSV changes the SSV, we
    are also protected from replay attacks.

    Disadvantage: if a file handle is protected with
    privacy, SET_SSV will not provide that protection.

    Advantage: little disruption to draft-10.
    
(2) Allow EXCHANGE_ID and/or CREATE_SESSION
    to create a special RPCSEC_GSS handle
    on the server that uses the SSV as the key for
    integrity protection and privacy protection. Currently
    there is to means to specify the OID of a privacy algorithm
    along with an integrity algorithm; this would have to added
    (in the same place where the integrity algorims for the SSV
    are specified). A client could, if the client and server have
    agreed at the time the EXCHANGE_ID/CREATE_SESSION handshake
    completes, use this special RPCSEC_GSS handle 
    to issue CLOSE, LOCKU, etc. A side benefit is that
    for callbacks, the SSV could be used as well; draft-10
    allows the client to give to the server an RPCSEC_GSS
    handle that it got from the server, and with it an RPCSEC_GSS
    handle that maps to the same GSS context, which the server then
    uses on callbacks. The client just as easily give the server
    the SSV-derived RPCSEC_GSS handle. This way, the SSV-derived
    GSS context never expires.

    Advantages: 
               - privacy now allowed
               - callback gss context never has to expire
               - no need to add yet another GSS mechanism
                 (indeed I was going to offer an SSV-based GSS
                 mech as a third alternative, but I couldn't
                 see much point to it).

    Disadvantage:
               - more .x changes to draft-10 (but the point of
                 formal inspection was to fine holes, so we
                 we may need to get over it)

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 21 May 2007 15:22:35 -0400

>     privacy, SET_SSV will not provide that protection.

The other disadvantage is that it forces you to serialise all stateful
operations that are protected in this way. You simply cannot have
multiple SET_SSV requests on the wire at the same time.

>                  we may need to get over it)

I'd prefer this approach.

Are you still advocating attaching the initial SET_SSV to the
EXCHANGE_ID operation?

Cheers
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Mon, 21 May 2007 12:29:25 -0700 (PDT)

> multiple SET_SSV requests on the wire at the same time.

That's a good point and it is very big disadvantage.

> Are you still advocating attaching the initial SET_SSV to the

I was planning to make the SSV apply to the clientid instead of
just the session per the feedback from the i-d sessions inspection
meetings. I don't recall any discussion about creating the
SSV at the time EXCHANGE_ID was done, but I haven't reviewed all
the notes from the inspection meetings recently.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 21 May 2007 16:08:06 -0500

On May 21, 2007, at 2:10 PM, Mike Eisler wrote:

>     uses on callbacks.

I like this approach in general and very much so for this side benefit.

Spencer

> The client just as easily give the server