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