Eduardo Tongson wrote:
Robert Watson's paper discusses concurrency vulnerabilities. Impact
include policy bypass and audit trail invalidation. A bypass means it
is useless. That pretty much hammered in the last nail on the coffin
for security tools based on system call interposition.
I actually dont think it is all worthless. Imagine a machine running a
server daemon. If you systrace that particurlar daemon to not be able to
fork()/exec*() or system(), you could be quite sure it wont start random
apps on your machine in case someone manages to trick it somehow.
Now, if the attacker already has a local account and/or shell, he might
run races and fool the systrace. But if this daemon was the only way for
said attacker to gain such shell access, and it can be prevented from
doing common stuff needed to get a local shell then you would have a
"safer" system.
In this way, systrace might be usable still, even though it wont suffice
for systrace'd shells given out to bad guys. Same as all other measures
you might have like chroots, stack gaps, randomized mem layouts and
library addresses, they never prevent 100% of all attacks, just many of
them.
On 10/15/07, Steve Shockley <[EMAIL PROTECTED]> wrote:
Joachim Schipper wrote:
You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).
The white paper for the systrace vulnerability was a little bit beyond
me; what's the impact of the issue? Is a system running systrace *more*
vulnerable than a normal system, or is the problem just that a
determined user can circumvent systrace (like the bottom of systrace(1)
suggests)? If it's the latter, it seems like it'd still be useful for
policy enforcement to some extent.
