We've already passed over Microsoft's Data Execution Prevention and why it doesn't work without real Address Space Layout Randomization. This is because a simple ret2libc attack can be used to evade normal memory space protections that systems such as DEP and PaX take advantage of. This is why other systems employ ASLR.
Red Hat is also hyping their security. In an earlier post to the LKML, Red Hat has submitted parts of Exec Shield for mainline inclusion, to add ASLR. These patches allow a 64KiB stack base randomization and a 1MiB mmap() base randomization. I pointed out that this is not adequate, because small gaps in the stack can be easily compensated for:
[...]|STACK---STACK---NONONOSHELLCODE STACK---STACK---NONONOSHELLCODE ----------------------^ | -- You jump here in any case.
Brad Spengler of GrSecurity also had a few things to say about this randomization patch pertaining to the extremely short brute-force cycle needed to break it. He also points out the maintainers' complacency with a glibc information leaking bug that they pretend to have fixed even though it's still in the wild. Apparently, though, the bug was fixed; but the fix was never marked as a security update, so many users including some Red Hat developers are likely still affected.
Interestingly enough, this is the same kind of problem OpenBSD has with its stack-gap randomization being easily evadable. The problem may be that they're more interested in confusing attackers than developing real solutions. That's not to say that they don't occasionally get things right.
So what kinds of things are real? Security auditing for one. This is part of the most basic security fundamentals: finding and fixing flaws. Projects such as the Debian Security Audit Project and Gentoo Linux Security Audit exist for this purpose. Packages such as SAL, Flawfinder, and RATS are created for automated auditing.
There are several distributions focused on real security, such as Adamantix and Gentoo. Ubuntu Linux may also be coming this way thanks to the efforts of the Hardened Debian project and, of course, the gracious concern of the Ubuntu lead developers.
Adamantix, Hardened Gentoo, and even Ubuntu's experimental security-hardened kernels include GrSecurity to enhance the security of the system by randomizing various information important to attackers such as PIDs and networking intrinsics and obscuring this information from non-privileged users. GrSecurity also hardens
chroot() jails to prevent various break-outs, for example by using mknod and mount; and supplies other restrictions to prevent tempfile races.
While Adamantix and Hardened Gentoo are not large community distributions, Ubuntu is a Debian-based distribution aiming at presenting a more user-friendly, desktop-appropriate environment. This makes Ubuntu a portal to the community's eyes to show how to properly assess which security enhancements are appropriate and how to deploy them; and to demonstrate their effectiveness and non-intrusiveness to the user's environment.
As long as this community of related projects works together, continued security development should be expedient and efficient. Unilateral attempts to reinvent all security systems create a confusing environment where individual implementations have their own strengths and weaknesses, and often don't display a clear affinity to one 'best' product. A joint attempt piles all development energy into correcting all flaws in a single effort and enhancing the project, creating the most polished final product possible.