[13187] in bugtraq
Re: strace can lie
daemon@ATHENA.MIT.EDU (Pavel Machek)
Sun Jan 2 15:52:23 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19991228231820.K204@bug.ucw.cz>
Date: Tue, 28 Dec 1999 23:18:20 +0100
Reply-To: Pavel Machek <pavel@SUSE.CZ>
From: Pavel Machek <pavel@SUSE.CZ>
X-To: Misha Dankov <Misha_Dankov@F9.N5037.Z2.FIDONET.ORG>,
bugtraq@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <946385523@f9.n5037.z2.fidonet>; from Misha Dankov on Tue,
Dec 28, 1999 at 12:51:32PM +0300
Hi!
> >> Any ideas how to get rid of this problem? It is nasty. It is
> >> very nasty and makes strace unusable for anything
> >> security-sensitive.
>
> dM> Unfortunately, as long as the information is fetched from
> dM> userland by userland via ptrace, with an opportunity for it to
> dM> change before the kernel uses it, there is no hope for
> dM> eliminating the race.
>
> dM> If you really feel ambitious, you could try to make Linux support
> dM> ktrace. :-)
>
> I beleive there is a workaround: one can assign RealTime Scheduler to
> debugger process (sched_setscheduler (strace_pid, SCHED_FIFO, p)) so it will
> preempt any of processess being debugged. Of course, scheduling priority of
> strace should be higher than one of process if process works under RT
> scheduler too.
That will not work on SMP machine, and it will not be reliable on UP,
either (what if you hit pagefault? what if tracer accesses filesystem
and sleeps?).
Pavel
--
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
