From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28466 invoked by alias); 24 Dec 2008 19:26:58 -0000 Received: (qmail 28459 invoked by uid 22791); 24 Dec 2008 19:26:58 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_20,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_20,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Dec 2008 19:26:22 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mBOJQKQH002874 for ; Wed, 24 Dec 2008 14:26:20 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBOJQKcX003174 for ; Wed, 24 Dec 2008 14:26:20 -0500 Received: from [127.0.0.1] (vpn-12-180.rdu.redhat.com [10.11.12.180]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBOJQIRS004431 for ; Wed, 24 Dec 2008 14:26:20 -0500 Message-ID: <49528CDE.2070508@redhat.com> Date: Thu, 25 Dec 2008 06:52:00 -0000 From: Dave Brolley User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: systemtap@sources.redhat.com Subject: Systemtap Compile Server Phase 2 (SSL) Now Available Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes 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: 2008-q4/txt/msg00646.txt.bz2 Hi Everyone, I just pushed the changes for the next phase of the Systemtap Compile Server, which is the use of SSL for secure connection between the client and server and for signing of the server's response. This is a first cut implementation and some work is still needed to make it more robust and easily usable, but you should be able to play around with it now without many problems. The major change, for usability, is in the management of the certificates and keys which are used to authenticate each server. Currently, much of the work is done for you as follows: 1) Running 'make' will generate a server certificate and key database in $bld/ssl/server. A copy of the server's certificate will also be generated in $bld/ssl/server/stap-server.cert. A certificate database containing the server's certificate will also be created for the client's use in $bld/ssl/client. 2) The simplest way to use the client/server is to install it using 'make install'. This will install the server's certificate and key in /etc/systemtap/ssl/server and the client's copy of the server's certificate in /etc/systemtap/ssl/client. You can then simply stap-start-server stap-client Note that since the server requires access to its private key, only the user who ran the 'make install' can start the server in this way. However, any user can use the client against a running server. 3) If you want to run the client or server out of the build tree you can use: stap-start-server $bld/ssl/server stap-client --ssl=$bld/ssl/client Since the server needs access to it's private key, only the user which did the 'make' can run the server out of the build tree. However, any user can use the client against a running server using the client's copy of the certificate from the build tree. 4) Any user can create his own certificate/key in order to start a server using stap-gen-server-cert This will generate a server certificate and key database in /server. A copy of the server's certificate will also be generated in /stap-server.cert. A certificate database containing the server's certificate will also be created for the client's use in /client. This user can then start a server using stap-start-server /server stap-client --ssl=/client Since the server needs access to it's private key, only the user which generate the certificate/keys can start the server with this certificate/key. However, any user can use the client against a running server using the client's copy of this certificate. 5) A user wishing to access different servers can either use the --ssl option on stap-client each time or he can add the certificate of each server he wishes to use to his local certificate database using stap-add-server-cert /client where is the stap-server.cert file from the server's certificate/key database directory and is the directory used on stap-gen-server-cert. This is analagous to adding your ssh public key to the authorized_keys file on machines you wish to access using ssh. One known bug is that full path names are currently required when specifying the certificate database directories on stap-start-server and stap-client. Let me know what you all think and if you see or find any problems. Thanks, Dave