From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16999 invoked by alias); 30 Oct 2008 21:23:44 -0000 Received: (qmail 16540 invoked by uid 22791); 30 Oct 2008 21:23:37 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50,KAM_MX X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Oct 2008 21:20:38 +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 m9UIQ5vR024450 for ; Thu, 30 Oct 2008 14:26:05 -0400 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 m9UIQ5Aa029405 for ; Thu, 30 Oct 2008 14:26:05 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m9UIQ5xC012566; Thu, 30 Oct 2008 14:26:05 -0400 Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id m9UIQ4ok023328; Thu, 30 Oct 2008 14:26:04 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m9UIQ4xT023327; Thu, 30 Oct 2008 14:26:04 -0400 X-Authentication-Warning: ton.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Dave Brolley Cc: systemtap Subject: Re: Network Security for the Systemtap Client/Server References: <4900E8AE.9090407@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 30 Oct 2008 21:23:00 -0000 In-Reply-To: <4900E8AE.9090407@redhat.com> (Dave Brolley's message of "Thu, 23 Oct 2008 17:12:14 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00240.txt.bz2 Hi, Dave - Thanks for your writeup. > [...] > Wire Level Security > ------------------- > Wire level security is necessary to prevent spoofing (impersonation) of > systemtap servers as well as eavesdropping on the data stream > between the client and server (man in the middle). The first of those threats is not so bad, considering module signing. The second is not that bad. But a third, modification of the script en route to the server, is bad, and justifies efforts to secure the wire. > Authentication of clients is also possible although may not be > necessary. [...] Agreed. > [...] > 2) Use the NSS C language API for SSL from within stap to communicate with > the server. The stap-client script would still create the request as a > directory tree [...] It would then call stap, passing it the name of > the archive. stap would then send it to the server [...] It seems clumsy to have to use stap just so that it can do stunnel-like data transfer. Is there a perl binding to NSS, so that a rewritten stap-client could use it. Maybe nss_compat_ossl.... Or, really, we can buck the fedora trend briefly and go with plain openssl (with stunnel and/or perl bindings) until NSS becomes similarly functional. > [...] > Module Signing > -------------- > It is desirable that the client be able to verify that the data returned from > the server has not been tampered with. This can be accomplished by digitally > signing the data. Once again NSS provides facilities for signing and > verifying arbitrary data. An extra complication here is that module signing is mainly there to help enable future systemtap use by unprivileged users. The trusted server would impose extra constraints and return a probe module that compiles in any additional checks needed. The signature on such a module needs to be carried through right through to staprun - beyond stap-client - since staprun is the setuid piece that must ultimately decide whether to load/run a proposed module or not. It needs to perform the signature verification to assure the local system(admin) that the possibly unprivileged user who ran stap-client did not mess with the resulting module. (Doing all this via the kernel module-signing code in some kernels would not be appropriate, according to its author.) > [...] > Administration > -------------- > Here is how a sysadmin would administer a trusted systemap server. All > commands below must be executed as the userid which will run the server. > [...] All that must be automatable to death. The wire protocol part's user interface should be no clumsier than, say, svn talking to a https: server. The module signature verification is a whole separate mechanism. There, the sysadmin-approved list of module-signing public keys need to be installed into a special place ($etcdir/systemtap/server-keys), which staprun would validate against. - FCHE