[13113] in bugtraq
Re: strace can lie
daemon@ATHENA.MIT.EDU (der Mouse)
Mon Dec 27 18:53:53 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <199912272035.PAA04991@Twig.Rodents.Montreal.QC.CA>
Date: Mon, 27 Dec 1999 15:35:05 -0500
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
> Any ideas how to get rid of this problem? It is nasty. It is very
> nasty and makes strace unusable for anything security-sensitive.
Unfortunately, as long as the information is fetched from userland by
userland via ptrace, with an opportunity for it to change before the
kernel uses it, there is no hope for eliminating the race.
You could perhaps run *BSD and use ktrace, which does eliminate the
race, because the kernel itself handles trace generation using the same
bits that it uses to look up the path. (It is also somewhat less
disruptive to the traced process.) Of course, there's a downside, too
- while the Linux emulation (at least under NetBSD, the one I know) is
pretty good, it's not perfect, so if you have Linux-specific things you
need, they may break.
If you really feel ambitious, you could try to make Linux support
ktrace. :-)
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
