This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need some security advice for systemtap


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]