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." -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list