The 2.6 Linux kernel has brought many general improvements to Linux system performance, capabilities, and capacity. The most commonly-noted of these are performance and responsiveness improvements, support for greater amounts of memory, better processor utilization and scaling in SMP environments, and integrated support for newer devices and interfaces such as Serial ATA. However, beyond these pleasant and immediately-noticeable improvements, many internal and system-level changes have occurred that enterprise system administrators should be aware of. RHEL4 and the 2.6 kernel provide many other improvements to administrative tools and capabilities - this section highlights my favorites.

Some of the most immediately visible and important changes introduced by the 2.6 Linux kernel are changes to loadable kernel module (LKM) naming conventions, internals, and build models. LKMs now end with the .ko extension (kernel object) to differentiate them from standard object files, have a simpler Makefile/build structure, and can more easily be built outside the kernel source by simply referring to the base location of a writable kernel source tree. If you are currently using devices whose drivers were supplied by a hardware or software vendor, you will need to obtain 2.6 versions of those drivers (assuming that they have not been folded into the official 2.6 kernel source).

Beyond server improvements and enhancements, RHEL4 and the 2.6 kernel give system administrators new levels of access control and system event monitoring. By using a recent version of the 2.6 kernel, RHEL4 introduces support for the light-weight auditing framework that provides interfaces that lower the overhead of providing audit information from the kernel and system applications. I couldn't find the audit daemon or associated applications on RHEL4, but at least the framework is present in the kernel--mechanisms for taking advantage of it can be distributed and RHEL4 updates, I suppose.

More importantly (and usable immediately), RHEL4 supports Security-Enhanced Linux (SELinux), which can be deactivated during the install process but is active by default. SELinux provides a variety of mechanisms for implementing and enforcing access control policies, including those based on the type of object being accessed (type-based) or on the role of the user attempting to access an object (role-based, commonly known as Role-Based Access Control, RBAC). SELinux access control policies operate outside the standard Linux protection and access control mechanisms, and are designed to limit user programs and system servers to the minimum privileges that they require in order to perform their tasks. A correct SELinux policy implementation can go a long way towards limiting the potential damage that can be done by exploiting server or application vulnerabilities through common techniques such as buffer overflows.

Next: Wrapping Up »