Re: Possible systemtap/NSS areas of extension

[Nathan Scott <nathans@redhat.com>]

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