- Operational Security
- Windows Development Model
- FreeBSD Development Model
- Linux Development Model
- Parting Shots
Linux Development Model
Linux is a very different animal from FreeBSD. Even though they're both open source operating systems, the Linux development model is much less coordinated. Linux, at its core, is simply a kernel. The core system utilities, including many of the drivers and tools that administrators use every day, are created by a different community and chain of command than those of the core kernel (see Figure 3). The Linux kernel is a discrete entity that's developed outside direct input from the rest of the "Linux community." From a security standpoint, this means that security capability that's created in the userland utilities is not necessarily reflected in the core kernel (and vice versa).
Figure 3 Linux is only the kernel with distributions that package the systems utilities and applications.
The kernel and userland applications are then integrated by a distribution (such as Red Hat or Debian) to create a complete operating system. The distributions may change some of the kernel or userland code when the code is integrated together. Some of these changes are minor "glue" changes; others are major pieces of new functionality. Each distribution handles integration in its own fashion, and this effectively makes each distribution its own operating system. So, rather than thinking "Linux," you must think "Red Hat" or "Debian" or "Mandrake," etc. when you're determining operating systems for your enterprise.
With respect to release planning and security functionality, each distribution has its own schedule and technology roadmap. For a while, Red Hat maintained a security roadmap (basically, it consisted of "integrate SELinux into the core OS"), but that seems to have been abandoned. Similarly, each distribution controls its end-of-life process, so there is no single "Linux EOL."
Patching in Linux-based operating systems is a bit of a two-part process. When a vulnerability is discovered, the vulnerability is disclosed to the original maintainer of the code. The original maintainer then releases a patch for the vulnerable software. Each distribution must pick up the patch and create a custom patch specific to their code base. At this point, administrators can then apply the patches to their system. This two-stage patch process can cause delay in the patching process; more importantly, it can cause confusion and configuration management problems.