Need some security advice for systemtap

[Pavel Kankovsky]

On Mon, 18 Jun 2007, David Smith wrote:

> > This might work but be very careful when you do it while multiple threads 
> > are running.
> 
> I believe I see what you mean here - if one thread raises privilegs 
> while another thread performs a security-sensitive operation, we've got 
> a problem.

Exactly.


On Mon, 18 Jun 2007, Martin Hunt wrote:

> "-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. 

It depends on the script. I can imagine a script that is safe as long as
the pid is yours but becomes dangerous when you can give it other pids.
E.g. a strace-like script peeking into data being read and written.

You need to establish a policy: either the blessed must never leak
potentially sensitive data (and the strace-like script is not eligible to
be blessed) or -x must be disabled.

> 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. 

Unless the parent process is stopped at the right moment...

> Run with sudo or root:
> >sudo /sbin/insmod close.ko
> >sudo chown hunt.hunt /sys/kernel/debug/systemtap/close/*

The idea of granting access to systemtap control channel to mortals
gives me the creeps and I won't feel better unless you can prove it is not 
possible to cause any harm when untrusted data is written to the 
control channel. What about STP_SYMBOLS?


On Tue, 19 Jun 2007, Stone, Joshua I wrote:

> This should be manageable.  When a child process exits, it sends a 
> SIGCHLD and sits as a zombie until the parent has wait()ed for it.  As 
> long as it's a zombie, the pid won't be recycled.
> 
> We just need to notice in our sig handler that the start_cmd process 
> died, and make sure we don't try to kill the pid after that.

There's still a race condition there:

1. the parent process checks the flag, the child is still alive
   and flag is reset, ok, let's kill the child
2. the child dies spontaneously, SIGCHLD handler sets a flag
   and reaps the child's zombie
3. the parent send a signal...oops!

It might help to block SIGCHLD temporarily. Or to take waitpid() away from
the signal handler and reap zombies synchronously in the main loop.

BTW: Is it always safe to call send_request() in a signal handler?
And fprintf()? (See <http://lcamtuf.coredump.cx/signals.txt>)


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."