Differences between Distribution Kernels

It is not uncommon to run a Linux system with a kernel that was compiled for another distribution. One reason for doing this is the difficulty in compiling and testing a kernel to make sure it will do what you require. It’s not THAT difficult for someone who knows what they are doing, but if someone else has already done the work then it seems like a waste to re-invent the wheel. Sometimes it’s an issue of a driver that one distribution supports but not another, copying the entire kernel package from another distribution may be easier than compiling a new kernel with the extra driver. Sometimes it’s a kernel bug, if distribution A has fixed the bug and distribution B hasn’t, then it’s often easier to install a kernel package from distribution A when running distribution B.

Another reason for running different distributions with the same kernel is Xen. If you have a Dom0 which hosts instances for different distributions as DomU’s then running the same kernel on all of them can make it easier to manage.

Unfortunately it’s not uncommon for different distributions to have different kernel feature sets. One example I’m currently dealing with is the fact that the Debian/Etch kernel is compiled with CONFIG_AUDITSYSCALL disabled while RHEL and CentOS require it. So if you run a RHEL or CentOS system with a Debian kernel (EG running a Debian Xen server with a RHEL or CentOS DomU) then you see messages such as the following in your logs.

crond[7824]: pam_loginuid(crond:session): set_loginuid failed opening loginuid

The loginuid feature allows login and equivalent programs (which includes xdm and other graphical login programs, cron and every other program that runs a program on behalf of another user) to set the loginuid. This loginuid will be stored by the kernel, inherited across fork() and exec, and not be changed by running setuid or setgid programs. Therefore if you see some strange entries in your audit log indicating an attempted attack you can determine the original login UID of the person responsible.

In terms of security features it’s not a really high priority. But it is really annoying when programs that work on RHEL don’t work properly with a Debian kernel and put many unwanted messages in the log files. For people who have less background knowledge about these things it may be more than annoying, and may even force them to change their deployment plans to make the message go away (not everyone knows which messages can be ignored or where to ask about such things).

The fact that Etch has no user-space support for the auditing features in question (auditing system calls or setting the loginuid) was never a good reason for not enabling this feature (IMHO). Using the auditing system calls was simply a matter of copying the auditctl program from a RHEL, Fedora, or CentOS system (for those who didn’t feel inclined to compile the source). The loginuid required changes to PAM to enable it, but is actually a small part of the auditing layer.

As a general rule minimising the differences between distribution kernels is going to benefit most people. Some people complain about kernel bloat, but there are worse candidates for that accusation and given that it seems impossible to buy a machine with less than 512M of RAM and a 900MHz CPU (the specs of the ASUS EeePC) adding a few extra kernel features seems unlikely to hurt anyone. It is of course always possible to compile your own kernel for the smallest machines.

Finally I am in the process of back-porting SE Linux code and related security features to Etch, and having this already enabled in the kernel would make my work easier. I won’t do a 7 year support cycle for it unless someone pays, but supporting Etch past the release of Lenny with the latest SE Linux features (and the current features working properly) is my aim.