Project review: GSS credential store extensions

[Simo Sorce]

On Thu, 2012-07-12 at 12:12 -0400, Greg Hudson wrote:
> On 07/12/2012 10:19 AM, Sam Hartman wrote:
> > I'd like to speak in support of const char * here at least for the URN
> > parameter.
> 
> I believe this came up earlier, though I can't find a record of it.  No
> one from the GSSAPI community seemed to favor buffers.
> 
> > We should also think about the use of an elements struct in terms of our
> > experience with GSS-API memory allocation.  As designed today all the
> > element struct manipulation is left up to the application. The down
> > sides there are that it makes it expensive and messy if the mechglue or
> > a stacked mechanism wants to manipulate the element set.
> 
> Nico brought this up on kitten and I (and Simo) disagreed.
> 
> I know everyone wishes buffers were different (though I'm not sure how)
> because of the twin problems that (1) applications call
> gss_release_buffer on buffers they themselves allocated, creating memory
> bugs, and (2) the mechglue returns buffers allocated by either itself or
> a mechanism, and can't tell which one when it comes time to release.
> 
> (2) is only a problem because buffers are used for wrapped and unwrapped
> messages, which we don't want to take the extra time to copy.  If it
> weren't for that, the mechglue could avoid returning mech-allocated
> buffers to the caller.  Since cred stores are not used for
> performance-sensitive GSS calls, I don't think that problem applies here.
> 
> Both problems only apply if we start communicating cred stores to the
> caller instead of vice versa.  All of the suggestions I saw for which we
> might do this--like asking for the default cred store location of a
> mechanism--were ideas I didn't particularly like.
> 
> > Also, it forces
> > applications to do a bunch of redundant memory management and everyone
> > is probably going to write there own release functions.
> 
> This cuts both ways.  If the application happens to have a way of simply
> managing its cred store content pointers, then making the cred store
> type opaque forces it to do a lot of extra work and check a lot of error
> conditions.
> 
> > Is this intended to replace gss_acquire_cred_with_password? I.E. can I
> > "get" a credential from a password, or a password and smart card, or a
> > PIN and smart card? I'm not asking whether you plan to implement that so
> > much as whether that usage is compatible with this architecture.
> 
> I believe Simo's intent is to leave the door open to this with "the
> store can specify both the actual credentials and/or the credential
> location."  Personally, I'm not sure it's a good idea.  It would let you
> supply a richer set of secrets than just a password, but only if you
> know what secrets you need to provide ahead of time.  Also, "the actual
> credentials" could include internal nulls (for instance, the key from a
> keytab), while credential locations typically would not.

The primary cred store function is to be able to store these strings in
config files.

It has been said alrteady a few time that "raw" secrets  *SHOULD NOT* be
passed as values, at most you can pass the location of a file with those
contents.
This is one of the reasons I *do* want to keep (const) char * for
values, as I do not want people to try to cram binary values.
It makes it impossible to put them in config files because of
uncertainty around escaping among other issues related to storing binary
values in text files.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York