Re: [pkcs11] Fwd: Re: [pkcs11-comment] PKCS#11 Usage Guide vs. POSIX issue

[Darren J Moffat <Darren.Moffat@Oracle.COM>]

On 05/11/15 23:09, Tim Hudson wrote:
> FYI - David's response ...

We do use pthread_atfork() in the Solaris delivered PKCS#11 libraries 
and it has been hard to get it properly implemented.  We have that added 
complexity that we have PKCS#11 plugged into PKCS#11 and the fact we use 
PKCS#11 in other libraries.

All of our libraries would actually have worked just fine in the child 
and the parent of the fork() but we have had to add code to break that. 
 This is particularly difficult to deal with then PKCS#11 is several 
layers of library and plugin below the application that called fork().

The standard should be updated to remove the whole requirement to 
C_Finalize() in the child of fork() - PKCS#11 should not specify 
anything about fork other than it should be fork safe (ie the child can 
continue to use the handles).  It makes PKCS#11 unlike any other crypto 
library and makes it very difficult to use - it has been the cause of 
some very serious and hard to debug problems for us.  Especially when 
PKCS#11 is actually plugged in underneath another crypto API (OpenSSL 
via ENGINE or JCE via JNI calls to PKCS#11).

When you fork() in UNIX you *are* still running with the same 
credentials so there really is no reason to invalidate the connection to 
the PKCS#11 "subsystem". The time when you potentially want to invalid 
is on exec() or maybe on setreuid() calls, not on fork().  If the 
PKCS#11 library uses a file descriptor as the "connection" to some 
backend that authenticated the user at C_Login() then you can set the fd 
to be closed on exec.  If you really think you need to deal with 
setreuid() calls then you are a) probably wrong and going to break 
legitimate uses or b) you are part of the OS and have other potential 
hooks available to you, but even then see a).


Darren J Moffat

> -------- Original Message --------
> Subject: 	Re: [pkcs11-comment] PKCS#11 Usage Guide vs. POSIX issue
> Date: 	Mon, 11 May 2015 21:03:51 +0000
> From: 	Woodhouse, David <david.woodhouse@intel.com>
> To: 	tjh@cryptsoft.com <tjh@cryptsoft.com>
> CC: 	pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
>
>
>
> On Tue, 2015-05-12 at 06:50 +1000, Tim Hudson wrote:
> > David, it appears to my reading of your email at least - that all of
> > the issues you are raising are related to implementation issues with
> > specific vendors and/or some vendors use of pthread_atfork ... and
> > not with the specification itself.
>
> Yes, in a sense that's true.
>
> But it seems like using pthread_atfork() is one of the only obvious
> ways to implement the "good Cryptoki programming practice" of calling
> C_Initialize() whenever the application forks.
>
> We don't spell it out, but we are *leading* the developer to use
> pthread_atfork(). I'm not quite sure how else one would implement the
> recommendation and expect it to cover fork() from arbitrary library
> routines, etc.
>
> Given that the obvious implementation of what we recommend is a clear
> violation of the POSIX specification when we do it from a multi
> -threaded process, surely it warrants at least a *caveat* that perhaps
> the reader might want to bear the POSIX requirements in mind?
>
> Sure, we are *only* leading them to the cliff, and we didn't make them
> jump. But maybe we could point it out to them?

--
Darren J Moffat