Linus has been pushing 2.4 development snapshots regularly. I have been pulling them, building them, and reading parts of them on a test machine for a few evenings. The shape of where Linux is going is becoming clear, and several of the changes are operationally significant for defenders.
This post is the read-up. Not a comprehensive review; a few things that stood out.
netfilter is in and ipchains is out
The firewall framework I wrote about in February is in and replacing ipchains as the primary mechanism. The old ipchains interface is preserved as a compatibility shim — your existing rule sets continue to work — but new development is happening against iptables.
In practice this means:
- Existing
ipchainsconfigurations continue working when you upgrade to 2.4. You do not have to rewrite immediately. - New features (connection tracking, NAT integration, modular match types) are only available through
iptables. - The compatibility shim is documented to be transitional. By 2.5 (the next development series) it will probably be deprecated; by 2.6 (the next stable series) it will likely be gone.
My practical recommendation, for anyone planning a 2.4 deployment: rewrite your rules in iptables syntax during the upgrade window. Use the connection-tracking features. The new rule structure is meaningfully cleaner than the ipchains translation.
USB is finally first-class
This is operational rather than security-specific, but worth mentioning. USB device support in 2.4 is, on the available evidence, finally usable. The 2.2 USB support was experimental and patchy. The 2.4 USB stack handles most modern USB devices natively, with hot-plug working reliably.
The security implication is that USB devices are now part of the threat model in a way they were not before. A USB stick plugged into a Linux box is now mounted automatically; the contents are accessible to whichever user the auto-mount runs as. This is fine for desktops, less fine for servers in environments where USB ports are accessible.
For a server, the right configuration is to disable USB hot-plug entirely. The kernel option is CONFIG_USB_DEVICEFS=n and the hotplug package's USB integration. Most distributions will ship with hot-plug enabled by default. Worth being explicit about disabling on production hosts.
The new VFS layer
The 2.4 kernel substantially rewrites the virtual filesystem layer. Most of this is performance-focused — better caching, more efficient handling of many open files, improved write-back behaviour. Some of it has security-relevant consequences.
Filesystem capabilities are starting to appear. A new attribute system on filesystems can carry, eventually, POSIX capabilities on individual files. The kernel-side support is in place; user-space tooling is not yet ready. This is the foundation for moving away from the SUID-root pattern toward the more granular capability model.
Mount options are richer. New mount options like noexec (no executables runnable from this mount) and nosuid (SUID bits ignored) are now properly enforced for all filesystem types. nodev (device files ignored) too. These have been around for a while in patchy form; in 2.4 they are uniform.
My recommendation for production servers: mount /tmp, /var/tmp, and any user-uploaded-content filesystems with noexec,nosuid,nodev. This prevents an attacker who manages to write to those filesystems from being able to execute anything from there.
The new networking primitives
A few new networking-related additions worth knowing about:
Tagged frames and policy routing. Linux can now handle 802.1Q VLAN tags natively, and the routing decisions can use frame tags as input. This allows network segmentation at the kernel level that previously required external switches.
Faster TCP/IP. The 2.4 stack is, on the benchmarks I have run, roughly 30% faster than 2.2 for most workloads. The improvement comes from better cache utilisation, reduced lock contention, and a cleaner packet pipeline.
Connection tracking is in netfilter. I mentioned this in the netfilter context. The connection-tracking module exposes useful internal state — current TCP connections, NAT mappings, expected helpers for protocols like FTP — that other modules can build on. This is the foundation for several future features I expect to see.
The cleaner kernel boundaries
This is more architectural than operational. The 2.4 kernel substantially cleans up the boundaries between subsystems. The boundary between core kernel and loadable modules is firmer; the API for modules is more stable; the discipline for what counts as a public interface is clearer.
The security relevance is partly that kernel modules become slightly less terrifying. The interfaces a module needs are now defined more explicitly; the module can do less unconstrained damage. Partly it is that kernel module signing — verifying that a loaded module came from a trusted source — becomes a tractable problem in 2.4 in a way it was not in 2.2.
Neither of these is fully realised yet. The architecture is moving in a direction that supports them. Expect to see actual implementations over the next year or two.
What I am paying attention to
Three things specifically:
The release timing. The development snapshots are working but not yet stable. Linus has not committed to a date. From the kernel mailing list traffic, my read is that 2.4.0 is probably summer 2000. I am not deploying production hosts to it before then.
The distribution adoption curve. Slackware tends to be conservative about kernel updates; Red Hat and Debian are usually faster. By the time I deploy 2.4 to my own hosts, the distributions will have shipped versions that include backported fixes for whatever issues are found in 2.4.0 itself.
The compatibility surprises. Major kernel transitions always break a few things. The 2.0-to-2.2 transition broke ipfwadm semantics, broke a handful of less-common drivers, broke specific application assumptions about kernel interfaces. The 2.2-to-2.4 transition will be similar in shape. I will be reading the kernel mailing list closely for the first few months after release to watch the regressions emerge.
The bigger picture
Linux is, with 2.4, becoming a mature production-grade operating system in a way it was not yet in 2.2. The kernel has the features that commercial Unixes have had for years. The development discipline is at a level where security-conscious operators can use it for serious work without compromising on capability.
This is good news for the open-source security community. It is also a quiet shift in the industry — Linux is no longer the experimental alternative; it is the mainstream choice for new deployments. The commercial Unixes are slowly being displaced.
For my own future writing, this means more of the technical detail I write about will be Linux-specific. The general principles apply to any Unix-like system, but the specific commands and configurations will increasingly be Linux. This is a deliberate choice; the audience has shifted in the same direction.
More as 2.4 actually ships. The first stable release will be its own moment.