Linux is inherently not a secure operating system. The reason it’s not secure is because Linux was based on the architectural design of UNIX, and the creators of UNIX didn’t care about security – it was 1969 after all.
“The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes,” Dennis Ritchie wrote in his paper, “On the Security of UNIX” in 1979.
At LinuxCon in Boston on Tuesday, Red Hat’s James Morris, a Linux kernel developer who lives in Syndey, Australia, spoke about how Linux has evolved in the last ten years to overcome the inherent lack of a security model in Linux.
The problem, Morris said, is that when UNIX was designed in the late 1960s, everyone thought we’d have flying cars by now, but instead, we have Facebook. On one hand, we’re doing things today with computers that were maybe pipe dreams 40 years, yet we’re still relying on operating systems designed decades ago.
And that’s the challenge for Linux developers. Morris said that in order to secure Linux, software engineers have had to bolt security components onto and around the Linux kernel. The original security mechanism for Linux was UNIX DAC, then came POSIX, Access Control Lists, private and PID namespaces, cryptography, Linux Security Modules, SELinux, Smack, TOMOYO, AppArmor and the list goes on.
But with so many options to choose from, users can be overwhelmed. It’s sort of like going into a Cold Stone Creamery and being confronted with a list of possible ingredients and being expected to come up with your own custom flavor of ice cream. It’s easier to just pick from the pre-defined recipes, or to just go to the grocery store and pick up a pint of Cherry Garcia.
This myriad of security options on Linux is hindering adoption of security technology and setting up secure Linux servers and workstations. For example, a user or system administrator has to decide whether to turn on Smack, TOMOYO, SELinux or AppArmor. It’s not necessarily an easy decision to make since many of these technologies solve similar problems, but they do it in slightly different ways. For instance, Novell developed AppArmor for its SUSE Linux Enterprise server, and it competes with SE Linux. Novell publishes a side-by-side comparison of the two technologies on their AppArmor Web site. AppArmor has a much simpler configuration file format.
And we’ve yet to even talk about network security, storage security and malware prevention. This involves setting up Netfilter for packet filtering, or NuFW, which is an authenticating firewall based on Netfilter. To stop malware, there are several projects in various stages of development, such as fsnotify, TALPA and DazukoFS.
The biggest problem, Morris said, is adoption and “getting people to understand that security is necessary.”
“It’s not like seatbelts,” Morris said. “We can’t make laws” requiring that people setup secure Linux servers and workstations. We have to convince people, he said, that it’s in their best interest to do so.
So rather than overwhelming Linux users with a plethora of security options, Morris said, we need to make security as transparent as possible.
Transparency is one of the stated goals of AppArmor. Tony Jones of SUSE said, “AppArmor is designed to be highly transparent to applications: If you add AppArmor to a working system, you have to develop AppArmor profiles, but you do not have to change your applications. If you remove AppArmor from a running system, the system continues to operate exactly as before, but without the AppArmor security protections.”
And while the SELinux configuration files are more cumbersome than AppArmor’s, one of its goals is transparency too. Red Hat says, “SELinux plugs into the Linux Security Module (LSM) to handle access requests at the kernel level for multiple common network-facing applications. The SELinux-based security for these applications requires no extra administration and is transparent to users and applications.”
The benefit of greater transparency is that it can reduce the greatest threat to security, and that’s the human element. Too many people are like water in that they seek the path of least resistance. If a system administrator has to slog through lots of pages and write clunky configuration files to setup a secure system, many will simply get discouraged and bug off.
“Security is fundamentally a people problem,” security guru Bruce Schneier said.
Keith Vance is a software engineer and a journalist. He’s been developing web applications professionally since 1997 and he received his journalism degree from the University of Washington in 2008.
Follow eSecurityPlanet on Twitter: @eSecurityP.
