OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/6811
Full headers

From: rmeggins@redhat.com
Subject: Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
Compose comment
Download message
State:
0 replies:
5 followups: 1 2 3 4 5

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 28 Jan 2011 15:34:01 +0000
From: rmeggins@redhat.com
To: openldap-its@OpenLDAP.org
Subject: Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
Full_Name: Rich Megginson
Version: 2.4.23 (current CVS HEAD)
OS: RHEL6
URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110127.patch
Submission from: (NULL) (76.113.111.209)


There are some applications that acquire a crypto context in the parent process
and expect that crypto context to work after a fork().  This does not work
with MozNSS using strict PKCS11 compliance mode.  We set the environment
variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software
encryption module/token to allow crypto contexts to persist across a fork(). 
However, if you are using some other module or encryption device that supports
and expects full PKCS11 semantics, the only recourse is to modify the
application to use atfork() handlers to save the crypto context in the parent
and restore (and SECMOD_RestartModules) the context in the child.

These patch files are derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Red Hat. Red Hat has not assigned rights
and/or interest in this work to any party. I, Rich Megginson am
authorized by Red Hat, my employer, to release this work under the
following terms.

Red Hat hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose
with or without attribution and/or other notice.

Followup 1

Download message
Date: Sat, 29 Jan 2011 02:25:46 -0800
From: Howard Chu <hyc@symas.com>
To: rmeggins@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking
 for the software token
rmeggins@redhat.com wrote:
> Full_Name: Rich Megginson
> Version: 2.4.23 (current CVS HEAD)
> OS: RHEL6
> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110127.patch
> Submission from: (NULL) (76.113.111.209)
>
>
> There are some applications that acquire a crypto context in the parent
process
> and expect that crypto context to work after a fork().  This does not work
> with MozNSS using strict PKCS11 compliance mode.  We set the environment
> variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software
> encryption module/token to allow crypto contexts to persist across a
fork().
> However, if you are using some other module or encryption device that
supports
> and expects full PKCS11 semantics, the only recourse is to modify the
> application to use atfork() handlers to save the crypto context in the
parent
> and restore (and SECMOD_RestartModules) the context in the child.

Sounds like this is a followon to #6802. Is this really critical at this 
point? We really need to close the window on RE24 patches so we can actually 
cut a release. But if ITS#6802 is actually incomplete, I guess we should roll 
this in.

> These patch files are derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following
> patch(es) were developed by Red Hat. Red Hat has not assigned rights
> and/or interest in this work to any party. I, Rich Megginson am
> authorized by Red Hat, my employer, to release this work under the
> following terms.
>
> Red Hat hereby place the following modifications to OpenLDAP Software
> (and only these modifications) into the public domain. Hence, these
> modifications may be freely used and/or redistributed for any purpose
> with or without attribution and/or other notice.
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Sat, 29 Jan 2011 10:18:27 -0700
Subject: Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for
 the software token
From: Rich Megginson <richm@stanfordalumni.org>
To: openldap-its@OpenLDAP.org
Cc: rmeggins@redhat.com
On Sat, Jan 29, 2011 at 3:26 AM,  <hyc@symas.com> wrote:
> rmeggins@redhat.com wrote:
>> Full_Name: Rich Megginson
>> Version: 2.4.23 (current CVS HEAD)
>> OS: RHEL6
>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo=
rk-20110127.patch
>> Submission from: (NULL) (76.113.111.209)
>>
>>
>> There are some applications that acquire a crypto context in the parent
=
process
>> and expect that crypto context to work after a fork(). =A0This does not
=
work
>> with MozNSS using strict PKCS11 compliance mode. =A0We set the
environme=
nt
>> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the
softwar=
e
>> encryption module/token to allow crypto contexts to persist across a
for=
k().
>> However, if you are using some other module or encryption device that
su=
pports
>> and expects full PKCS11 semantics, the only recourse is to modify the
>> application to use atfork() handlers to save the crypto context in the
p=
arent
>> and restore (and SECMOD_RestartModules) the context in the child.
>
> Sounds like this is a followon to #6802. Is this really critical at this
> point? We really need to close the window on RE24 patches so we can actua=
lly
> cut a release. But if ITS#6802 is actually incomplete, I guess we should =
roll
> this in.

Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was
incomplete.  We have discovered some important applications such as
sshd/su/others that open an LDAP* connection in the parent process,
fork(), and attempt to use the same LDAP* handle in the child.  Some
of the other Fedora/Red Hat developers and I had a discussion with one
of the MozNSS developers about this issue, as ldap is not the only
affected area.  It was decided that the best thing is to simply
disable the fork() checking in the MozNSS software token pkcs11 crypto
module.  This will give us parity with openssl with respect to fork()
behavior.  It is a critical issue for Fedora/Red Hat.  I understand
that this is coming in late in the game and you may not be able to get
this into RE24.  If not, Fedora/Red Hat will carry a patch for this.

>
>> These patch files are derived from OpenLDAP Software. All of the
>> modifications to OpenLDAP Software represented in the following
>> patch(es) were developed by Red Hat. Red Hat has not assigned rights
>> and/or interest in this work to any party. I, Rich Megginson am
>> authorized by Red Hat, my employer, to release this work under the
>> following terms.
>>
>> Red Hat hereby place the following modifications to OpenLDAP Software
>> (and only these modifications) into the public domain. Hence, these
>> modifications may be freely used and/or redistributed for any purpose
>> with or without attribution and/or other notice.
>>
>
>
> --
> =A0 -- Howard Chu
> =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com
> =A0 Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/
> =A0 Chief Architect, OpenLDAP =A0http://www.openldap.org/project/
>
>
>



Followup 3

Download message
Date: Sat, 29 Jan 2011 11:39:14 -0800
From: Howard Chu <hyc@symas.com>
To: richm@stanfordalumni.org
CC: openldap-its@openldap.org
Subject: Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking
 for the software token
richm@stanfordalumni.org wrote:
> On Sat, Jan 29, 2011 at 3:26 AM,<hyc@symas.com>  wrote:
>> rmeggins@redhat.com wrote:
>>> Full_Name: Rich Megginson
>>> Version: 2.4.23 (current CVS HEAD)
>>> OS: RHEL6
>>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo=
> rk-20110127.patch
>>> Submission from: (NULL) (76.113.111.209)
>>>
>>>
>>> There are some applications that acquire a crypto context in the
parent =
> process
>>> and expect that crypto context to work after a fork(). =A0This does
not =
> work
>>> with MozNSS using strict PKCS11 compliance mode. =A0We set the
environme=
> nt
>>> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the
softwar=
> e
>>> encryption module/token to allow crypto contexts to persist across
a for=
> k().
>>> However, if you are using some other module or encryption device
that su=
> pports
>>> and expects full PKCS11 semantics, the only recourse is to modify
the
>>> application to use atfork() handlers to save the crypto context in
the p=
> arent
>>> and restore (and SECMOD_RestartModules) the context in the child.
>>
>> Sounds like this is a followon to #6802. Is this really critical at
this
>> point? We really need to close the window on RE24 patches so we can
actua=
> lly
>> cut a release. But if ITS#6802 is actually incomplete, I guess we
should =
> roll
>> this in.
>
> Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was
> incomplete.  We have discovered some important applications such as
> sshd/su/others that open an LDAP* connection in the parent process,
> fork(), and attempt to use the same LDAP* handle in the child.  Some
> of the other Fedora/Red Hat developers and I had a discussion with one
> of the MozNSS developers about this issue, as ldap is not the only
> affected area.  It was decided that the best thing is to simply
> disable the fork() checking in the MozNSS software token pkcs11 crypto
> module.  This will give us parity with openssl with respect to fork()
> behavior.  It is a critical issue for Fedora/Red Hat.  I understand
> that this is coming in late in the game and you may not be able to get
> this into RE24.  If not, Fedora/Red Hat will carry a patch for this.

Is this env var and atfork() workaround already documented in the NSS 
documentation? Just wondering if we need to say anything about it in our Admin 
Guide, FAQ-o-Matic, or manpages.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 4

Download message
Date: Sat, 29 Jan 2011 15:04:45 -0700
Subject: Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for
 the software token
From: Rich Megginson <richm@stanfordalumni.org>
To: openldap-its@openldap.org
Cc: rmeggins@redhat.com
The NSS_STRICT_NOFORK environment variable is documented here:
https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables

Note that if a user really wants the strict pkcs11 behavior, the user
can set the variable to "1" or some other non-empty value (other than
"DISABLED").

If you think further documentation is required, I would be happy to
update the Admin Guide, FAQ-o-matic, man pages, etc.



Followup 5

Download message
Date: Sat, 29 Jan 2011 14:30:52 -0800
From: Howard Chu <hyc@symas.com>
To: richm@stanfordalumni.org
CC: openldap-its@openldap.org
Subject: Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking
 for the software token
richm@stanfordalumni.org wrote:
> The NSS_STRICT_NOFORK environment variable is documented here:
> https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables
>
> Note that if a user really wants the strict pkcs11 behavior, the user
> can set the variable to "1" or some other non-empty value (other than
> "DISABLED").
>
> If you think further documentation is required, I would be happy to
> update the Admin Guide, FAQ-o-matic, man pages, etc.

That looks fine. Most of our docs were written specifically to OpenSSL but 
we've added one or two references to GnuTLS since then. I would start by 
adding to the FAQ-o-Matic:

http://www.openldap.org/faq/data/cache/196.html

I guess we could update this to mention the availability of GnuTLS and MozNSS 
support and perhaps a discussion of their pros and cons. (Though in all 
honesty I cannot think of any pros for using GnuTLS. I would use PolarSSL 
instead but that's not what the Debian folks asked for...)

Hm, this entire FAQ page is far out of date. If you want to add some MozNSS 
info here go ahead, I'll take a pass at the rest of the page later.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org