Developer Raps Linux Security

A developer of security software for Linux had some harsh words yesterday for what he sees as a lax attitude toward security in the operating system's community.

"Linux is being presented by commercial vendors as a professional, enterprise-ready product," Brad Spengler, of grsecurity, said. "When it comes to security, I don't see it as either professional or enterprise-ready."

Spengler has gained notoriety recently through articles posted on the Web criticizing Linux security in general and in particular the Linux Security Module (LSM).

Speed Trumps Security

According to the programmer, Linux kernel developers don't take security seriously. "Linus [Torvalds] has told me personally that he is not interested in adding even the option of very useful security features that can help prevent buffer overflow exploitation because using some of these features would make applications load a small fraction slower," Spengler said.

His frustration that performance is often given priority over security is one shared by many security professionals in all areas of IT, not just the Linux realm.

"Given the current trend in IT, performance is always given top priority over security," Vincent Danen, security update manager for Mandrakesoft in Edmonton, Alberta, Canada, said. "I also think that in a number of cases, features are given priority over security. This isn't something specific to Linux. You see this everywhere."

Spengler also groused about the absence of an official security officer for the Linux kernel to whom communication could be directed privately and securely.

"What we are told to do currently is to e-mail vendor-sec, which is a large list of people involved with vendors that will handle security issues," he explained. "However, they cannot be trusted (just recently the uselib() exploit was leaked or stolen from vendor-sec) and they cannot be communicated with securely (they have no PGP key)," he told LinuxInsider via e-mail.

Blackhats Dance, Vendors Fiddle

While "blackhats" exploit stolen information from vendor-sec, vendors on the list sit on the vulnerabilities, he asserted. "What results is that the vulnerabilities are being exploited for weeks while Linux users as a whole are unaware that there is a vulnerability," he said.

Mandrakesoft's Danen, a member of vendor-sec, noted that the "leak" referred to by Spengler is still being investigated by the group. "We're thinking it's not necessarily a leak in vendor-sec," he said. "We think someone put a sniffer in front of one of the companies that was dealing with us on one particular vulnerability."

That company isn't part of vendor-sec, he explained, but it would be receiving copies of discussions about the vulnerability since it brought the problem to vendor-sec's attention.

LSM Loose Cannon

Spengler was also critical of LSM, which has been incorporated into version 2.6 of the Linux kernel. He characterized LSM as merely a way to allow the National Security Agency's SELinux to be used as a module. "The framework is unfit for any security system that does anything remotely innovative, such as grsecurity and RSBAC [Rule Set-Based Access Control]," he declared.

He contends that LSM provides many hooks deep into the inner workings of the kernel, which can be used just as easily by a rootkit (a program for hacking the root), or malware, as a legitimate security module. "The hooks LSM provides to rootkit authors were previously very difficult (or impossible) to obtain, so having LSM in the kernel, if unused by a security module that prevents rootkits, will result in new, advanced rootkits that will be nearly impossible to detect," he said.

Danen concurred with Spengler's analysis of LSM. "If I were building a 2.6 kernel, I would be disabling LSM," he said, "which means that I wouldn't be able to take advantage of technologies such as SELinux, but I don't really care. There are other alternatives that are just as good that don't require LSM."

"Some of this comes down to a matter of taste," averred Bill Weinberg, OS Architecture Specialist for Open Source Development Labs in Beaverton, Oregon. "They [grsecurity] have their own architecture that they would like to see in place, and [as] is so common in Open Source, they are critiquing the status quo in the open community, in the marketplace. Sometimes those discussions can become quite vociferous."