Security as debugging?

by davidnielsen

Something struck me today, I was reading a thread on the Ubuntu forums on wireless security and that started me thinking. Following the release of OpenBSD 3.8, being interested in security enhancements I read the release notes and they mentioned that they did some changes to the way they handled memory allocation to avoid those nasty stack smashing attacks.

This gave me the following idea, the notes mentioned they had an even more aggressive mode but that tended to cause to much trouble and slowdown – however this would catch mode misbehaving software. Now catching misbehaving software is a good thing and during the development cycle of a distro like the wonderful Fedora Core if one could enable such a feature to catch bad bugs, but since it might cause to much breakage it would be disabled for the first many production releases. However it would slowly weed out bad bugs at the root, sorta in the same tone as causing fatal warnings to crash GNOME during development releases (a tactic which is being debated right now on d-d-l, and I fully support).

Would this fly I wonder?

The end goal would be in say 3 or 4 cycles to have the environment prepared to have these features enabled by default for maximum security but untill then using them as bug honeypots sounds tempting. Simply announcing that in say 3 cycles this would be the default in production release would also give ISVs time to adjust to this rather break happy but still within specification change.