Slackware 4.0 was released last week, with kernel 2.2.6. This is the first major Slackware release in the 2.2 kernel era, and after a fortnight of running it I want to write down what is genuinely different.
Most of the press coverage has focused on the kernel itself, which is fair — 2.2 is a significant rewrite and brings real improvements. But the more interesting story, from a defender's point of view, is what becomes possible above the kernel because of the changes the kernel makes.
What the kernel changes
The 2.2 kernel brings, among many other things:
A new packet filtering framework: ipchains, which I wrote about three weeks ago and which is now what you use to write firewall rules.
Smarter SMP support. Multi-processor systems work meaningfully better than under 2.0. The locking model has been overhauled.
A reorganised network stack. The TCP and UDP code is cleaner, faster on most workloads, and better aligned with what the RFCs actually say. I have been reading parts of it and the structure is much improved.
Better filesystem support. ReiserFS is approaching usability. The tmpfs filesystem is now standard. ext2 has been tightened up considerably.
Removable device handling. USB is still in development but getting closer. PCMCIA is much more reliable.
What this changes for security
A few things stand out after a fortnight.
The ipchains framework is a real upgrade. I am now able to express things in firewall rules that I genuinely could not in 2.0. Per-host counters, named sub-chains, more uniform syntax — all of it adds up to a setup that is easier to audit. The full migration of my home firewall took an afternoon and the result is markedly more legible.
Capabilities are starting to be usable. The 2.2 kernel adds POSIX capabilities — a fine-grained breakdown of what "root" means. Instead of a binary either-or between unprivileged and full root, a process can hold a small subset of root's privileges. For example, tcpdump needs CAP_NET_RAW to put an interface into promiscuous mode; it does not need any other root privilege; if you build it that way, it can be used by an unprivileged user without granting full root.
The support is rough. The user-space tooling is incomplete. Most distributions, including Slackware 4.0, do not yet exploit it for system daemons. But the primitive is there in the kernel, and over the next couple of years I expect to see it used to substantially reduce the privilege footprint of common services.
The new filesystem features matter for forensics. ReiserFS and journaled filesystems generally make it harder to recover deleted data — every action is logged through the journal, which makes some operations leave a clearer trail, but also means traditional file-recovery techniques become less useful. For incident response, this is double-edged: easier to reconstruct a sequence of events, harder to recover specific overwritten files.
What I miss
The transition is not without losses.
Some of my old ipfwadm muscle memory has had to be relearned. The new syntax is better but it is different, and I have a year of habit to undo. This is not a real complaint about Slackware — it is a real complaint about my own brain — but it is, in practice, the thing that has cost me most time during the migration.
A handful of older drivers no longer build. The kernel API for module developers has changed. Most projects have updated. A few have not. For one piece of obscure hardware on my old test machine, I had to stick with a 2.0 kernel for the moment.
The package count has grown. Slackware 4.0 ships with substantially more packages than 3.x. This is in keeping with where the community is going, but it makes the install procedure longer and the post-install audit (what is actually listening) more important.
What I have changed about my install procedure
A short list, distilled from the fortnight:
- Install minimal, then add packages as needed. The default "full install" includes a lot more than you want for a server. The X11 packages, in particular, should not be on a public-facing host.
- Disable everything in
/etc/inetd.conf, then enable only what you need. The Slackware 4.0 default is more conservative than 3.6 was, but still includes things that should not be on by default. - Migrate firewall rules to
ipchainsdeliberately. Theipchainspackage includes a tool to convert oldipfwadmrules; it works but the output is mechanical. Hand-rewriting the rules to use named sub-chains is worth the time. - Set up syslog with offsite forwarding as part of the initial config, not as an afterthought. The earlier you have offsite logs, the less you have to worry about local log integrity.
- Generate a fresh SSH host key the moment SSH is installed. The default keys generated during installation can be predictable across many installs of the same distribution.
A small operational note
The transition from 2.0 to 2.2 is the first time, in my own experience, where a major kernel bump has been a clearly net-positive event for security. Previous transitions — 1.0 to 1.2, 1.2 to 2.0 — brought useful kernel features but also introduced new issues at the same rate.
2.2 is different. The kernel team has been visibly more security-conscious than in previous releases. Several CERT advisories from the 2.0 era are not just patched in 2.2 but prevented by design. The structural improvements — capabilities, the new firewall framework, the cleaner network stack — represent a meaningful posture improvement, not just an incremental fix.
This is encouraging. The Linux kernel is becoming a tool that takes its own security obligations seriously, in a way that the BSD kernels have for years. The trajectory is good. We are not at the end of it but we are visibly moving down it.