Bug#732201: Please add libnssdb.a and libnssckfw.a to libnss3-dev

[Mike Hommey]

On Wed, Jan 15, 2014 at 06:12:51PM +0200, Timo Aaltonen wrote:
> On 14.01.2014 07:53, Mike Hommey wrote:
> > On Tue, Jan 14, 2014 at 07:12:50AM +0200, Timo Aaltonen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 14.01.2014 07:04, Daniel Kahn Gillmor wrote:
> >>> On 01/13/2014 11:57 PM, Timo Aaltonen wrote:
> >>>> On 13.01.2014 11:05, Mike Hommey wrote:
> >>>>> The contents of libnssb.a are in libnss3.so. Why do you need
> >>>>>  libnssb?
> >>>> 
> >>>> For an apache module called mod_rev.so, configure.in has:
> >>>> 
> >>>> if ! test -e "$nss_lib_dir"/libnssb.a then AC_MSG_ERROR([NSS is
> >>>>  installed but the PKCS11 development package is missing. Need
> >>>>  libnssb.a]) fi
> >>> 
> >>> can this be done with dynamic linking instead?  if you use a
> >>> static library, than any bugs found in nssb will mean we need to
> >>> update nss and *then* rebuild libapache2-mod-rev.  this seems
> >>> clumsier than just needing to update nss itself.
> >> 
> >> guess it's related to this snippet from README:
> >> 
> >> DEVELOPERS
> >> 
> >> This module uses some internals from NSS. This is normally a big
> >> no-no but there was no other way to get around it. As such a
> >> private copy of some of the NSS include files can be found in the
> >> mozilla subdirectory. If you use a version of NSS other than 3.9.3
> >> then you should replace the files in this directory with
> >> appropriate files from whatever version you are using.
> >> 
> >> and mozilla/README:
> >> 
> >> We need some private header files from NSS in order to build the
> >> module. Rather than checking them out at build time it is easier to
> >> include them here. We just need to be careful and watch for API
> >> changes.
> >> 
> >> 
> >> Fedora is the upstream, I could ask why it's like this.
> > 
> > Sounds like they should *really* talk with NSS upstream.
> 
> The reason is added security for PKCS#11, discussed on the spec:
> 
> ftp://ftp.rsa.com/pub/pkcs/pkcs-11/201final/spec/v201.pdf
> 
> from 5.2:
> 
> "The dynamic approach certainly has advantages as new libraries are made
> available, but from a security perspective, there are some drawbacks. In
> particular, if a library is easily replaced, then there is the
> possibility that an attacker can substitute a rogue library
> that intercepts a user’s PIN. From a security perspective, therefore,
> direct linking is generally preferable, although codesigning techniques
> can prevent many of the security risks of dynamic linking. In any case,
> whether the linking is direct or dynamic, the programming interface
> between the application and a Cryptoki library remains the same."

AIUI, cryptoki is in nssckfw. Leaving aside the false sense of security
in static linking, that doesn't explain why nss internals are needed. It
sounds to me like they need some guts exposed, and would need to talk to
NSS upstream to expose them.

Mike