[wynand]

If I had to give a name to this approach, I'd call it "adversarial debugging".

It's an excellent technique for software improvement, as it somewhat mirrors an evolutionary game. You have your prey (your software) and a predator (the chaos-like monkeys). When the predator is successful, you improve your prey until the predator is under control (with non-chaos monkeys). Then you improve your predator (chaos-like monkeys). This cycle of prey/predator improvement can be repeated as long as needed.

As saurik points out, this has the potential to lead to cascading failures. But this is true of any complex system that has multiple levels of self-repair - repair systems in biological systems can also work against the host organism.

I'd love to see commonly used software hardened in this way - Apache for example. Imagine a contest where the aim is to find creative ways to bring down sandboxed Apache servers (executed on the machine of the contest participant). You (the contestant) come up with an Apache killer and submit it to the contest website and get points based on how much damage your code can do. This gives the Apache developers an idea of where to harden Apache.

The obvious danger with such a system is that it's a treasure trove of DOS attacks against existing Apache installations. But the argument in favor is that some black-hats might already have similar code anyway and they won't be publishing their code. Also, the code is a good test harness that can be used to verify that major architectural changes (such as what would be needed to integrate Google's SPDY into Apache) don't make Apache vulnerable to previous attacks. And of course, other similar software (Nginx et al.) can also benefit from some of these test cases.