Re: strace can lie

Subject: Re: strace can lie
From: der Mouse (mouseRODENTS.MONTREAL.QC.CA)
Date: Mon Dec 27 1999 - 14:35:05 CST

• Next message: Zhodiac: "remote buffer overflow in miniSQL"
• Previous message: Kragen Sitaker: "Re: Announcement: Solaris loadable kernel module backdoor"
• Maybe in reply to: Pavel Machek: "strace can lie"
• Next in thread: Sampo Savolainen: "Re: strace can lie"
• Maybe reply: der Mouse: "Re: strace can lie"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> 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

                               mouserodents.montreal.qc.ca
                     7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

• Next message: Zhodiac: "remote buffer overflow in miniSQL"
• Previous message: Kragen Sitaker: "Re: Announcement: Solaris loadable kernel module backdoor"
• Maybe in reply to: Pavel Machek: "strace can lie"
• Next in thread: Sampo Savolainen: "Re: strace can lie"
• Maybe reply: der Mouse: "Re: strace can lie"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b27 : Mon Dec 27 1999 - 17:14:45 CST