From jaanus@kaboom.ml.ee Tue Dec 14 13:57:11 1999 Return-Path: Received: from abraham.cs.berkeley.edu (abraham.cs.berkeley.edu [128.32.37.121]) by blowfish.isaac.cs.berkeley.edu (8.8.7/8.8.7) with ESMTP id NAA30069 for ; Tue, 14 Dec 1999 13:57:11 -0800 Received: from cs2.CS.Berkeley.EDU (cs2.CS.Berkeley.EDU [169.229.60.56]) by abraham.cs.berkeley.edu (8.8.6/8.8.6) with ESMTP id GAA06156 for ; Tue, 14 Dec 1999 06:31:09 -0800 Received: from kaboom.ml.ee (kaboom.ml.ee [194.106.100.135]) by cs2.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id GAA03202 for ; Tue, 14 Dec 1999 06:28:43 -0800 (PST) Received: (from jaanus@localhost) by kaboom.ml.ee (8.9.3/8.9.3) id QAA06139; Tue, 14 Dec 1999 16:27:48 +0200 To: jaanus@kaboom.ml.ee From: daw@cs.berkeley.edu (David Wagner) Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.questions,comp.unix.solaris,comp.security.unix,alt.hacker Subject: Re: intercepting system calls Date: 12 Dec 1999 20:23:27 -0800 Organization: A poorly-installed InterNetNews site Lines: 40 Message-ID: <831sbv$f6i$1@blowfish.isaac.cs.berkeley.edu> References: <38514DFC.9F07128C@netvision.net.il> <831314$d7p$1@blowfish.isaac.cs.berkeley.edu> <38543EEF.8851B311@ibm.net> NNTP-Posting-Host: joseph.cs.berkeley.edu X-Trace: agate.berkeley.edu 945059135 22257 128.32.37.122 (13 Dec 1999 04:25:35 GMT) X-Complaints-To: abuse@berkeley.edu NNTP-Posting-Date: 13 Dec 1999 04:25:35 GMT Path: news.infonet.ee!newsfeed.uninet.ee!newsfeed1.funet.fi!newsfeed1.telenordia.se!news.algonet.se!algonet!newsfeed.berkeley.edu!agate.berkeley.edu!agate!not-for-mail Xref: news.infonet.ee comp.unix.internals:1100 comp.unix.programmer:16519 comp.unix.questions:14217 comp.unix.solaris:51503 comp.security.unix:9137 alt.hacker:11172 X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Status: RO In article <38543EEF.8851B311@ibm.net>, Pat Gunn wrote: > David Wagner wrote: > > In Solaris, use the /proc filesystem. It is far better than ptrace. > > I don't understand how it's better than ptrace -- > it seems to me that you'd do an awful lot of polling of things in /proc > and very likely would miss events. You won't "miss events" with the /proc filesystem: they are queued up in the kernel until you receive them. The tracing process will typically issue a blocking call to /proc that only returns when some event is available. (select() and polling functionality are also available.) The problems with ptrace are subtle and hard to explain, but they are there. Go read the source code of strace sometime if you want to see some examples: it is amazingly convoluted. For example, race conditions abound with ptrace. Just try to reliably trace all children of a given application, without missing events -- there are two or three different race conditions here to watch out for. As another example, because ptrace uses signals to deliver events, it changes some of the semantics of signals and wait() for traced applications. (ptrace also slightly modifies the parent-child relationship of Unix processes, which may have strange consequences.) These effects require arcane workarounds in the tracing process to restore transparency, so applications don't break when they are being traced. Finally, the Solaris /proc filesystem offers many pieces of important functionality which are unavailable with ptrace. One may select just a subset of the system calls to watch; one may easily follow all children of the traced application if it forks; one may prevent selected syscalls from being executed; and so on. If you want a disgusting amount of detail on some esoteric and undesirable quirks of ptrace, see Chapter 12 of the following technical report: ``Janus: an approach for confinement of untrusted applications'' http://www.cs.berkeley.edu/~daw/papers/janus-masters.ps I report on a security tool that uses ptrace, and on some of the pitfalls I encountered in building the tool.