Need some security advice for systemtap

[David Smith]

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 at redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)