Possible systemtap/NSS areas of extension

Possible systemtap/NSS areas of extension

[Nathan Scott]

Hi all,

I've been working with Dave Brolley recently to introduce
SSL/TLS support in PCP.  Its been sometimes convenient to
refer to the existing SSL/TLS support code in systemtap in
the process of doing this (this is to do with the compile-
server code, for reference, which uses the NSS TLS/SSL TLA
implementation).

As is always the case, the underlying libraries have moved
on a bit since the initial implementation, so I thought I'd
send out a list of potential areas we've found in which the
systemtap implementation might be extended / added to down
the track, in areas that have changed.

1. error codes
- the NSS libraries seem to have acquired a more flexible
  error code -> error string translation mechanism, that
  spans the nss, nspr and sec error code/string tables.
  systemtap maintains its own list in stapsslerr.h - this
  could nowadays be replaced with library calls, which'd
  remove the need to maintain this dup'd code->string map
  (which has become slightly out-of-date with new versions
  of NSS).

2. password handling
- there's a PK11_GetPassword interface which (apparently)
  provides an extensible way to extract a password from an
  unsuspecting user.  In stap-land, there's an open-coded
  implementation of a password request/response mechanism
  that deals only with someone entering passwords via the
  keyboard.  That case, and the more exotic cases of thumb
  readers, card readers, etc could potentially be handed
  off to NSS itself.

3. database formats
- NSS now supports databases in a number of different formats.
- In particular, shared databases (i.e. shared by applications
  on one machine) are now supported, via the sqlite format.
- I *think* systemtap will accidentally not allow these other
  formats, as its assuming the path specification really is a
  filesystem path.  Nowadays however, NSS will accept database
  format prefixed paths like "sql:/etc/pki/nssdb" and others
  too (dbm:, rdb: ... not looked more deeply into those though).
- cert_db_is_valid effectively checks via access(3) whether a
  given path is valid, which I think would cause these alternate
  (prefixed) NSS database formats to be rejected.

4. system-wide NSS database
- There appears to be a move toward consolidation of system/host
  certificate databases, at least for NSS-based databases.  An
  API has been added to facilitate transitioning to use of the
  system-wide shared SQL NSS database - NSSInitWithMerge.  It'd
  be an option for systemtap, if transitioning to the new form
  is considered a desirable feature at some point, to use this
  to merge the existing systemtap database with the system-wide
  database.

That's about it so far, I think.  If anything else comes up I'll
send further updates.

cheers.

--
Nathan

Re: Possible systemtap/NSS areas of extension

[Josh Stone]

On 02/14/2013 01:46 AM, Nathan Scott wrote:
> 4. system-wide NSS database
> - There appears to be a move toward consolidation of system/host
>   certificate databases, at least for NSS-based databases.  An
>   API has been added to facilitate transitioning to use of the
>   system-wide shared SQL NSS database - NSSInitWithMerge.  It'd
>   be an option for systemtap, if transitioning to the new form
>   is considered a desirable feature at some point, to use this
>   to merge the existing systemtap database with the system-wide
>   database.

Perhaps I misunderstand you, but we need to be really careful due to
what is implied by the certificates we accept.  We need not just "this
host's claimed identity is confirmed" but also "I trust this host to
feed me a module which I'll load in my kernel."  A systemwide database
for the likes of internet browsers is certainly not suitable for that
kernel level of trust.

Re: Possible systemtap/NSS areas of extension

[Nathan Scott]

Hi Josh,

----- Original Message -----
> On 02/14/2013 01:46 AM, Nathan Scott wrote:
> > 4. system-wide NSS database
> > - There appears to be a move toward consolidation of system/host
> >   certificate databases, at least for NSS-based databases.  An
> >   API has been added to facilitate transitioning to use of the
> >   system-wide shared SQL NSS database - NSSInitWithMerge.  It'd
> >   be an option for systemtap, if transitioning to the new form
> >   is considered a desirable feature at some point, to use this
> >   to merge the existing systemtap database with the system-wide
> >   database.
> 
> Perhaps I misunderstand you, but we need to be really careful due to
> what is implied by the certificates we accept.  We need not just
> "this
> host's claimed identity is confirmed" but also "I trust this host to
> feed me a module which I'll load in my kernel."  A systemwide
> database
> for the likes of internet browsers is certainly not suitable for that
> kernel level of trust.

If its good enough to trust all my banking details to, I guess I'd
trust my kernel to it as well.  ;)

But seriously, you make a good point.  I note the stap-servers cert
DB path is setup for only stap-server to read and write, whereas the
/etc/pki/nssdb is setup for only root to write and anyone to read.
Also, stap-server is doing relatively exotic things with certificates
(signing and trusting its own certificates, etc) and programatically,
so putting these in the same system DB might not make sense.

I might have missed it in the earlier mail, but theres a move to also
be able to share the per-user certificates in ~HOME/.pki/nssdb as well
which the stap client might consider using too.

I think from an admin point of view, using common locations would make
life easier (in terms of sharing CA certs, revoking certs, etc - tools
like nss-gui point to the standard locations by default, and so on) -
but it might well not be suited for systemtap.

cheers.

--
Nathan