Re: What credentials should a setuid process use after fork (was Re: Client state security a

--- Trond Myklebust <trond.myklebustfys.uio.no> wrote:

> On Mon, 2007-05-21 at 12:10 -0700, Mike Eisler wrote:

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

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

> 
> >     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)
> 
> I'd prefer this approach.
> 
> Are you still advocating attaching the initial SET_SSV
to the
> EXCHANGE_ID operation?

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. 


_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4