Am 02.01.2015 um 20:46 schrieb Pavel Machek: >>> Does this break trinity, crashme, and similar programs? >> >> If they fork() without execve() and a child dies very fast the next fork() >> will be throttled. >> This is why I'd like to make this feature disabled by default. >> >>> Can you detect it died due to the stack canary? Then, the patch might >>> be actually acceptable. >> >> I don't think so as this is glibc specific. > > Can the slowdown be impelmented in glibc, then? glibc has a lot of asserts where it can detect stack smashing and kills the current process using abort(). Here it could of course also call sleep(). > If not, can glibc provide enough information to the kernel to allow us > to do the right thing? IMHO we should not strictly focus on the stack canary. If an attacker can kind of control the attacked child and it segfaults the generic in-kernel bruteforce detection will still work. Many exploits use the fact that after fork() the child has the same memory as before and brute force is possible. A user space solution won't help here. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
