On Tue, Sep 23, 2003 at 04:40:03PM +0100, Charles Blundell wrote:
> I have written the code for two extra options to systrace that I
> think will help when systrace comes across less than usual situations.
> 
> They are:
> 
> Randomly cause system calls to fail.

This is an excellent debugging tactic.

It would be better with one additional attribute - a way to specify a
seed for a PRNG, so that regression tests could record various test-case
paths.

Yes, it'll break whenever additional system calls that draw from the
PRNG go into the codepath, but I think it would still be useful. Even
better if different syscalls could draw from different PRNGs, which
would extend the lifetime of a regression test.

> Terminating a process when a system call not in its policy is
> attempted (only for unsupervised processes.) May help with policy
> probing attacks, and the problem noted above with kill.

I can't think of a good use case for this yet - besides DoSing yourself.
Perhaps if you could make sure the process would leave a core file
around it would be useful for debugging.

> Is either these two features worth having? Comments?
> 
> My current diff is at:
> ftp://ftp.NetBSD.org/pub/NetBSD/misc/cb/systr-erratic.diff

The first is great - commit when you're ready. The second is okay, but
I'd like to hear an explanation of its usefulness.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering, 
unthinking mass.  This is the same reason why you probably don't tell your 
boss about everything you read on BugTraq!    - Signal 11