Date: Sun, 8 Dec 1996 12:50:03 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: truss, trace ?? Message-ID: <199612080150.RAA20512@freefall.freebsd.org> In-Reply-To: <199612072157.WAA23260@uriah.heep.sax.de> from "J Wunsch" at Dec 7, 96 10:57:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612080150.RAA20512>