As Linux becomes more prevalent in today’s enterprise systems, it raises questions about the best way to protect the open source technology. David Humphrey, senior technology advisor for Ekaru, a Westbrook, Mass.-based technology services company, discussed some of those issues with Security Pipeline.
Security Pipeline: How would you describe where Linux security stands today as compared to three to four years ago ?
Humphrey: Linux has never had to face the challenges that Microsoft Windows faces now (and in the past) in those areas of security that we are most familiar with today. Specifically those relating to client use of an OS.
Conversely, Unix (and the many variants of Linux that have been derived from it), has traditionally been the operating system of choice for servers throughout the Internet. This has been true since “Al Gore invented the Internet” (all right, BBN in Cambridge).
IP-based vulnerabilities were the first targets for those trying to break into these networks. This kind of exposure led to a hardening of the OS; lessons on configuring the operating system; and protocol improvements, that, over the years, have reduced this type of security attack.
Three to four years ago, Linux was pretty well nailed-down, and it is even more so now. With table-based IP rules built into the kernel that can examine network traffic for security, VPN functionality similarly migrated directly into the kernel, the Linux of today is even more secure than yesterday.
Security Pipeline: Is security still viewed as a huge issue for open source computing?
Humphrey: There are two distinct sides of the coin to open source computing: the motivated geniuses that pump out code for a specific new application, and the very commercial world that has a different use for the open source community. An example here would be Sun's Java environment.
In the former case, security has never been a huge concern for much of the community.
Open-source here means you put something very cool together and you make it work. "It" being so very cool, you plunge forward with a "sourceforge.net" site, and tell all your friends what a nifty toy you have just created. They give you feedback, suggest code changes, and break it repeatedly until you regret ever telling anyone about it in the first place.
However, after repeatedly being embarrassed over just how poorly the code performs in areas of security (among other things), the interested community finally patches it up into something in the 14th major revision that can stand on its own without being a security nightmare.
In the end, you can get some amazing software from a dedicated community that is very secure. It may not have started that way, but it will inevitably mature there.
In the latter case however, security is part of the development plan day one. No one in Sun, IBM or Redhat wants to be the target of an identified security risk as it's bad for business.
This side of the coin will suffer similar evolutionary corrections to address security and functionality issues, but the difference in getting to that stage is enormous. It's a much more closed development cycle with a specific goal in mind. Security may not be that goal, but staying in business will just have to do.
So the open source-computing world can have widely varying issues with security, but they are likely to pale in comparison with the issues that arise from the Microsoft environment itself.
And there is something of a cross-culture mix here with open-source software on Microsoft. For example: if you put an open source IRC client on your Windows machine, is the reason that your system has been compromised within 20 minutes of logging onto an IRC channel the result of underlying security issues with the IRC client, or the operating system that invites complete access to all of its internals for any application that runs on it? Where is the security failure?
Unix/Linux doesn't collapse like this. You can actually install and run this same client as a non-privileged user on Linux that is relatively secure for the rest of the computer (and it's users).
Security Pipeline: What's been the top advancement in Linux and open source security?
Humphrey: The biggest advancement over the recent years in Linux security has also been the simplest: ship an OS tem that is relatively "locked down" by default. It is then necessary for the user to open it up to potential security threats, as part and parcel of setting it up to do specifically what it should do. This is what Redhat, SuSE, Debian, and the rest have been doing.
There are very few security surprises ready for the user installing Linux as he/she has to open up the system intentionally. Right behind that is going to be the nagging reminder that a compromise in your FTP server is going to have occurred as a result of weak security configuration.
Probably, the next big area of advancement is the overall security improvements made to release 2 of the libc library that is at the core of Unix/Linux operating system. This caused a major release in all of the Linux variants that made us all recompile re-target and rewrite all of the open source code to the new libraries. While this started happening more than four years ago now, it wasn't until three years ago that admins finally upgraded to the newer kernel.
Security Pipeline: What are your top tips for making the Linux environment as secure as possible?
Humphrey: Take the time and do it right, with nearly all of the open-source code available, there are guidelines on how to correctly set permissions for the install, how to use security tools like 'chroot', and how to set up an account without a login shell. The hassle for the overloaded admin is that it takes time and sometimes research. In security, the old saying “you get what you give” is more than just apropos.
Secondly, don’t install or enable any process or service that isn’t required.
Security Pipeline: Beyond what you've already discussed, any other suggestions or cautions for those dealing with Linux security?
Humphrey: Review the “best practice” procedures out there on how to setup your Linux system securely. There are still a few references left on the Internet on how to do this.
However, as you peruse these guides, you’ll notice that they are all years old. As I noted before, the security landscape hasn’t changed that much over the years; nonetheless, the guides are still a great way to understand the basics of today’s security (an example of such a guide can be found at http://www.cert.org/tech_tips/usc20_full.html).