Pavel Machek wrote: > David Wagner wrote: >> There was no way to follow fork securely. > >Actually there is now. I did something similar called subterfugue and >we solved this one.
Yes, I saw that. I thought subterfugue was neat. The way that subterfugue was a clever hack -- albeit too clever by half, in my opinion. Dynamically re-writing the program on the fly to insert a trap after the fork() call, right? When the tracer has to do that kind of thing, I find it hard to get confidence that it will be secure. It seems all too easy to imagine ways that the tracee might be able to escape the tracing and break security. There are all sorts of corner cases to think about. What if the program is executing from shared memory? What if there are multiple threads running concurrently? What if the program is executing from a region of memory where a DMA is scheduled to asynchronously write to? Any of those cases could create a race condition (TOCTTOU) where the trap after the fork() gets removed before the program reaches that point of execution. ptrace() seems like a fine answer for a debugger, but I think it's not such a great answer for a security tool where you have to be dead-certain there is no way to escape the sandbox. When I'm relying upon something for security, the last thing you want is to have to go through hairy kludgy kludgy contortions to make up for flaws in the interface. Complexity is the enemy of security. I still think that ptrace() is not the best way to implement this kind of security tool, and I think it's entirely understandable that they did not use ptrace. I do not think it is a fair criticism of AppArmor to say "AppArmor should have used ptrace()". >> Handling of signals is a mess: ptrace overloads the >> signal mechanism to deliver its events, [...] > >We got this solved in linux, I believe. Out of curiousity, how was this solved? It looked pretty fundamental to me. Thanks for your comments... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/