Subject: Re: systrace features?
To: David Maxwell <david@crlf.net>
From: Charles Blundell <cb@netbsd.org>
List: tech-security
Date: 09/24/2003 09:34:15
on Tue, Sep 23, 2003 at 10:00:08PM -0400, David Maxwell wrote:
> 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.

Neat. Will do.

> > 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.

For system calls like getpid and getuid, returning an error can
really mess things up.  I have not yet thought up anything worse
than a mass killing spree.  Maybe something with setreuid.
setreuid(-1, getuid()) where getuid is not in the policy.
But because a program may be expecting something to not fail,
systrace could cause a problem that would not normally exist.

Also, a compromised process will hopefully diverge from its expected
behaviour.  Currently, the attacker will just see EPERM from these
system calls, but is left free to explore the quality of the policy.

With -k, we see that the process is not behaving as expected and
kill it before any further shenanigans.

> Perhaps if you could make sure the process would leave a core file
> around it would be useful for debugging.

Something like -k abort might be handy for forensics too, I suppose.
(why/how did this process diverge)