Open source software security

Beyond Linux Security

31 March 2011
Luc de Louw's Blog recently presented an article on hardening RHEL systems based on critique and updates of the NSA's seminal, and 200 page, "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" (http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf). Luc's post gives some extra guidance on security configuration that I think is well reasoned and worth noting. I think it also points to the fundamental problem with Linux security in general, however. Linux is a compilation of several different building blocks. You have the kernel, the GNU coreutils, all the other services and programs from Gnome to Sendmail and cron, and then you have all sorts of customization and individualization depending on the system deployment environment and intended purpose. Ultimately this renders any sort of security discussion for "Linux" moot. You can't really discuss "Linux security" because the conversation quickly devolves into securing the various and sundry services and programs that make up a Linux system. "Linux security" is sort of a misnomer because any Linux system's security posture depends largely on the security of the different programs that run on top of the kernel. Therefore it is much more appropriate to speak of Linux filesystem security, using sudo, securing Apache, secure drive partitioning, auditing processes, and so on. Each of these topics is broad enough to deserve it's own book and by lumping it all together under Linux security you create a Sisyphean task. A quick glance at the NSA guide confirms this as the chapters quickly devolve into discussions about security various types of systems. Not that I think a Linux security guide is a bad endeavor, I just think folks should realize that it's a monster topic and is best handled in chunks. System daemons should probably be approached with their own individual security in mind. This would allow us to peg Linux security to a few core system functions (such as filesystem, users and groups, auditing and logging, and so on). By separating out MySQL security, Apache security, Bind security, SSH security, and so forth we might be able to manage the leviathan of Linux security without drowning in the task.