Re: Need some security advice for systemtap

[Martin Hunt <hunt at redhat dot com>]

On Mon, 2007-06-18 at 14:44 -0500, David Smith wrote:
> Pavel Kankovsky wrote:
> > On Mon, 11 Jun 2007, David Smith wrote:
> > 
> >> (D) staprun.auth will need to disallow certain staprun.auth command-line 
> >> arguments, such as:
> > 
> > Plus:
> > 
> > - "-u USERNAME" (assuming you allow -c, otherwise it has no effect;
> >   on the other hand, its support in staprun can help to to make it 
> >   possible to use -c via staprun.auth)

The only reason for "-u" is so we can currently do things like 
>stap -c "make all" systrace.stp
and have "make" execute as a normal user rather than root (because stap
does "sudo staprun").  

If staprun is not run by root, the setreuid() call will just fail if
someone tries to misuse it.

> > - "-t PID" (or "-x PID") (you need to disallow this because it is
> >   virtually impossible to avoid race conditions when you check whether
> >   a user is allowed to mess with a certain running process; alternatively,
> >   you can allow it and make it a requirement for blessed scripts that
> >   authorized users can attach them to any running process without
> >   compromising the security of the system)

"-x pid "doesn't actually do anything except cause target() to return
pid. So disabling it would be pointless. It exists as a convenient way
to pass a value to scripts that wish to filter based on pid. 

> > BTW1: staprun should close the file descriptors it uses internally 
> > (control fd, relayfs fds) when it executes the target program given by -c.
> 
> Good idea, I'll work on that.
> 
> > 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. 

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. 

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/*

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?

Martin