Standardizing on Security
The Linux standards group publishes 565 pages of data describing a standards-compliant Linux package. So why aren't any of them about security? 
By Hal Flynn Security Focus 

Things that are created in an open fashion tend to be the best of breed. They benefit from the entire world seeing them at their most basic level, and parties collaborating to enhance them and make them better. Open technology is an example of this. 
The Internet would be very different today had it not been built on the open model. Through Requests For Comments (RFCs), Internet Engineering Task Force drafts, and other open forums, the development and discussion of ideas and technologies has flourished into standards that, despite their age, are as good now as when they were conceived. In most cases, open is best, because it produces the best results. 
This rule has not held true with Linux security standards, which are virtually nonexistent. The open-source community is quick to cast haughty judgment on any software suffering security problems that is not open source; like a purple chicken, these products are singled out and pecked to death. But there have not been significant changes in the security model of UNIX, and by extension, Linux, in at least a decade. Linux security has failed to benefit from the open development model it claims makes it the best. 
Don't get me wrong I'm not saying that there haven't been significant developments in Linux. A number of really good security technologies have been built for Linux in the last few years: Pluggable Authentication Modules (PAM), originally conceived inside Sun Microsystems, is one such technology; Non-Executable Stack protection is another. And Rule Set Based Access Control is a worthy product of Linux's open-source and open-development environment. 
Our problem is not making the system work, it's in taking the fruits of our labors and making them staples of Linux security through standards and practical use.
But few of these technological advances have become any sort of standard. The security software is developed, released to the public with full source, and in most cases continuously maintained as Linux continues to evolve. Yet, at best, adoption has been haphazard, with various components popping up here and there in distributions, without continuity. In most cases, the end user has to perform a significant amount of work integrating these various technologies. If you get into APIs and default programs, there is even less consistency. 
Little Security Benefit 
Security needs to be written into Linux's DNA. And I would argue that the logical place to do that is at the Linux Standard Base, an open standard group dedicated to tackling the breaks in continuity across distributions, and creating baseline expectations in programs and APIs that allow software to run on any compliant system. 
In open collaboration with the powerhouses in the Linux industries -- IBM, Intel, The Open Group, SuSE, Mandrake, and others -- LSB drafted a document specifying the rules for Linux systems. The current revision, version 1.3, is not light reading: The document contains 565 pages of data outlining things such as object format, dynamic linking standards, libraries, packages, commands, system initialization, and the environment. In all, a total of twelve different sections specify detailed standards for compliant Linux systems. 
And sadly, nothing in the entire specification is new in terms of security. Of the advanced Linux security technologies I list in this column, only PAM is even mentioned in the document. Even staples of secure communications such as SSH have not made their way into the specifications. In fact, probably the most monumental item in the entire document that could be construed as a security enhancement is the exclusion of telnet in the commands and utilities list. 
Maybe it's the non-conformist attitude haunting us. Instead of doing something sensible and boring with the technology we create, we choose not to conform, and instead do nothing. Our problem with open technology and development is not making the system work, it's in taking the fruits of our labors and making them staples of Linux security through standards and practical use. 
Until we weave our standards to include advanced security technologies as a basic component of all Linux systems, groups like the LSB will offer us little security benefit. And that's a shame.