From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8923 invoked by alias); 19 Jun 2007 19:57:01 -0000 Received: (qmail 8875 invoked by uid 22791); 19 Jun 2007 19:57:00 -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, 19 Jun 2007 19:56:57 +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 l5JJutrn006655 for ; Tue, 19 Jun 2007 15:56:55 -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 l5JJurMe029190; Tue, 19 Jun 2007 15:56:54 -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 l5JJup0Y010581; Tue, 19 Jun 2007 15:56:51 -0400 Message-ID: <46783502.8020800@redhat.com> Date: Tue, 19 Jun 2007 19:57:00 -0000 From: David Smith User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Martin Hunt CC: Pavel Kankovsky , "Frank Ch. Eigler" , fedora-security-list@redhat.com, Systemtap List Subject: Re: Need some security advice for systemtap References: <20070616150353.13DE.0@paddy.troja.mff.cuni.cz> <4676E0B5.5090706@redhat.com> <1182211361.7067.66.camel@dragon> In-Reply-To: <1182211361.7067.66.camel@dragon> 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/msg00613.txt.bz2 Martin Hunt wrote: > On Mon, 2007-06-18 at 14:44 -0500, David Smith wrote: >> Pavel Kankovsky wrote: >>> On Mon, 11 Jun 2007, David Smith wrote: >> >>> BTW2: Let's suppose start_cmd() creates a process running under an >>> unprivileged user. I think it can be killed (by the unprivileged user) >>> before it gets SIGUSR1 and the system might recycle its pid. Therefore >>> kill() in STP_START branch of stp_main_loop() is unsafe. >> Hmm. Got any ideas on how to fix this? > > So, while the module loads its probes, we kill the start_cmd() process > and create enough new processes to recycle the pid? Then staprun sends > either SIGKILL or SIGUSR1 to the wrong process? Theoretically, if we set > tens of thousands of probes, we would have a few milliseconds to do > this. I do agree it isn't a likely occurrence, but if it is possible to fix we ought to look at it. > Now that I've caught up on this discussion (sorry) I see we are simply > talking about the blessed module approach to security. So the only > issue here is how to load/unload the module, right? It seems like you > have some good ideas. Why are we worrying about staprun? Load the > module with your blessed loader, then staprun runs as a normal user. The > only problem I see is unloading the module automatically. The problem with the blessed loader approach is that: (a) it duplicates code with regular staprun (although perhaps not much) (b) unloading the module isn't possible So, Frank and I have been trying to think through other ideas. > BTW, you can kind of try this now. > > Run with sudo or root: >> sudo /sbin/insmod close.ko >> sudo chown hunt.hunt /sys/kernel/debug/systemtap/close/* Actually that doesn't work if /sys/kernel/debug hasn't been mounted before. > Now run staprun as a normal user >> staprun -A close > cpufreq-applet: close(17) = 0 > cpufreq-applet: close(17) = 0 > hald-addon-stor: close(4) = 0 > cpufreq-applet: close(17) = 0 > cpufreq-applet: close(17) = 0 > crond: close(5) = 0 > crond: close(5) = 0 > gpm: close(0) = 0 > cpufreq-applet: close(17) = 0 > cpufreq-applet: close(17) = 0 > DONE > ERROR: Removing 'close': Operation not permitted > ERROR: couldn't rmmod probe module close. > > -- > > Hmmm. So lets say we create stap_load owned by > root, group systemtap, and file permission would be 04110. > > stap_load is a C program that does something like > if (root) > insmod(modname) > else if modname is blessed && user is valid > insmod(modname) > endif > > stap_unload would be similar or it could be the same program with > an argument to indicate load/unload. > > Then rename staprun to staprun.bin and create a script, staprun: > if stap_load modname > staprun.bin modname ... > stap_unload modname > endif > > Are there problems with this approach? Having two different setuid programs isn't the best plan. One possible alternative could be: stap_load (setuid) inserts module, then forks and execs (as a user) "staprun -A". stap_load then waits for "staprun -A" to finish. After staprun finishes, stap_load removes the module. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)