Subject: Re: systrace features?
To: Charles Blundell <email@example.com>
From: David Maxwell <firstname.lastname@example.org>
Date: 09/23/2003 22:00:08
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
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:
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, email@example.comfirstname.lastname@example.org --> 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