Eduardo Tongson wrote:
quoted text
> 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.

quoted text
> On 10/15/07, Steve Shockley <steve.shockley@shockley.net> 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.