From owner-freebsd-hackers  Sat Dec  7 17:50:22 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id RAA20519
          for hackers-outgoing; Sat, 7 Dec 1996 17:50:22 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA20512
          for <freebsd-hackers@freebsd.org>; Sat, 7 Dec 1996 17:50:19 -0800 (PST)
Message-Id: <199612080150.RAA20512@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA240059803; Sun, 8 Dec 1996 12:50:03 +1100
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: truss, trace ??
To: joerg_wunsch@uriah.heep.sax.de
Date: Sun, 8 Dec 1996 12:50:03 +1100 (EDT)
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <199612072157.WAA23260@uriah.heep.sax.de> from "J Wunsch" at Dec 7, 96 10:57:54 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from J Wunsch, sie said:
> 
> As Darren Reed wrote:
> 
> > > Is there a comparable program for freebsd?
> > 
> > Be nice if there was an option for it to output (immeadiately) to stdout
> > rather than ktrace.out.
> 
> I'm afraid that the kernel risks to stall if you get it to write the
> trace into a FIFO.  But perhaps it's not too difficult to have
> kdump(8) doing some `tail -f' like magic?  This should effectively
> yield you a similar behaviour.

hmpf.

At the last Usenix Security Symposium, there was an award winning paper
done by a student on a program which had the ability to control the
success/failure of system calls made by another program.  Idea being,
you use this with Java applets or any other program you don't trust,
giving yourself a way to control what files it opens, sockets, etc.
This was possible because of Solaris's implementation of /proc and
its interface available for ptrace(2) which allows for the process
intercepting the system call (via ptrace) to return a value for the
system call (rather than allowing the system call to complete and return
a value), thus being able to force failures.  i.e. your monitoring program
might catch all chdir's and open's, and thus be able to detect when
something tries to open /etc/passwd (you can do a stat() on the pathname
being passed to open() and compare that with doing a stat() on /etc/pased)
and return -1 to that program rather than let the system call go on and
succeed.

Whilst we have ktrace(2) which works with ktrace(1) and kdump(2), there is
no ptrace(2) and it would appear that there are siginicant differences
between ptrace and ktrace that perhaps ptrace should be implemented ?
I image an implementation of ptrace(2) would allow for a truss-like version
on ktrace(1).

Darren