From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31556 invoked by alias); 5 Jun 2007 20:56:50 -0000 Received: (qmail 31549 invoked by uid 22791); 5 Jun 2007 20:56:50 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,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.31) with ESMTP; Tue, 05 Jun 2007 20:56:45 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l55KufAk023218; Tue, 5 Jun 2007 16:56:42 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l55KufTA023919; Tue, 5 Jun 2007 16:56:41 -0400 Received: from localhost.localdomain (dhcp-170.hsv.redhat.com [172.16.17.170]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l55KueMc010052; Tue, 5 Jun 2007 16:56:40 -0400 Message-ID: <4665CE07.20303@redhat.com> Date: Tue, 05 Jun 2007 20:56:00 -0000 From: David Smith User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: grundym@us.ibm.com, fedora-security-list@redhat.com, Systemtap List Subject: Re: Need some security advice for systemtap References: <4664691E.7010803@redhat.com> <20070605171957.GF11630@us.ibm.com> In-Reply-To: <20070605171957.GF11630@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-q2/txt/msg00482.txt.bz2 grundy wrote: > I think a good way to handle it would be to have a configuration file > like /etc/sudoers and setuid root stap (or staprun). The access control > would then be built into systemtap. > > Here are my ideas of what would make a "good" set of controls: > > - level of tap script they can run, e.g. guru mode code or not > - sections of the kernel they can access (maybe this is > better represented as what tapsets may they use) > - how much overhead are they allowed to put on the system > - are they allowed to look at data for other user's processes > - are they allowed to reference line #'s or direct memory addrs That sounds nice, but I'm worried about implementing such a feature correctly, on at least two levels. First, you assume that systemtap can correctly characterize the effects a script will have on the system. Then you want to add an ACL system into systemtap based on those effects. One advantage the proposed system has is that there *is* a human in the loop, a root user who will (hopefully) look at a script and check it out before "blessing" it. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)