From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20336 invoked by alias); 15 Feb 2013 04:56:41 -0000 Received: (qmail 20327 invoked by uid 22791); 15 Feb 2013 04:56:40 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Feb 2013 04:56:31 +0000 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1F4uUkA029936; Thu, 14 Feb 2013 23:56:30 -0500 Date: Fri, 15 Feb 2013 04:56:00 -0000 From: Nathan Scott Reply-To: Nathan Scott To: Josh Stone Cc: systemtap@sourceware.org Message-ID: <2042332300.3117989.1360904190732.JavaMail.root@redhat.com> In-Reply-To: <511D1873.9000807@redhat.com> Subject: Re: Possible systemtap/NSS areas of extension MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2013-q1/txt/msg00139.txt.bz2 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