This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Need some security advice for systemtap
- From: Pavel Kankovsky <peak at argo dot troja dot mff dot cuni dot cz>
- To: David Smith <dsmith at redhat dot com>, Martin Hunt <hunt at redhat dot com>, "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, <fedora-security-list at redhat dot com>, Systemtap List <systemtap at sources dot redhat dot com>
- Date: Sun, 1 Jul 2007 18:14:31 +0200 (CEST)
- Subject: Re: Need some security advice for systemtap
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."