Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel is 2.3.29. For those wanting to live on the bleeding edge, there is a 2.3.30 pre-patch in the testing directory; it seems to consist mostly of Alpha and PowerPC changes, a new driver for ZR36120/ZR36125 based frame grabber/overlay boards, more IPC updates, and a new i386 semaphore implementation.
The current stable kernel release remains 2.2.13. Progress toward 2.2.14 continues with 2.2.14pre9.
Fun with the capability bounding set. Capabilities were added to the Linux kernel in the 2.1 development series; they are a form of relatively fine-grained access control. They can represent, for example, the ability to send signals to processes you do not own, to bypass file permissions, or to bind to network ports less than 1024. The whole idea behind capabilities is to dole out special powers in a manner that is a bit more discriminating than the standard Unix "all or nothing" approach. Those of us who remember systems like VMS (and will admit to it) can just think "privilege" instead of "capability" and have a good understanding of what is going on.
While the 2.2 kernel understands capabilities, they have not yet really found their way out to the system administration and user levels. There are many issues that need to be resolved before strongly capability-based systems will start to appear; see the LWN kernel section from April 8 and April 15 1999 for coverage of some of those issues.
Meanwhile, with little fanfare, the 2.2.11 patch slipped in a little goodie which begins to make capabilities available for system administration tasks. This version added the idea of a capability bounding set: a list of capabilities that are allowed to be held by any process on the system. If a capability does not appear in the bounding set, it may not be exercised by any process, no matter how privileged.
The bounding set is exported via sysctl, so it can be seen in /proc/sys/kernel/cap-bound. The default value has all bits set (all capabilities enabled), so looking at the contents of cap-bound will yield -1.
The bounding set can be modified by writing a new value into the cap-bound pseudo-file. But there is a twist: capabilities may be removed from the set by root, but only one process (init) is allowed to add capabilities. For all practical purposes, once a capability is taken out of the bounding set, it is gone until the next reboot.
How would one use this feature? Imagine that you run a secure system, and are worried about loadable modules. You do not, however, want to remove modules from the kernel altogether - it is too useful to be able to piece the system together at boot time. Or perhaps you have a driver that only works as a module. Wouldn't it be nice if the system could load modules to initialize itself, then disable module loading forevermore?
It turns out that one capability, CAP_SYS_MODULE, is required to load or unload kernel modules. If you remove CAP_SYS_MODULE from the bounding set, no more modules can ever be loaded - just what the doctor ordered.
CAP_SYS_MODULE is capability number 16 (here is the full list). The bounding set is expressed as a bitmask; we simply need to write a value that has bit 16 cleared. Thus a command like this:
echo 0xFFFEFFFF ?> /proc/sys/kernel/cap-boundwill do the trick.
Needless to say, be very careful when making changes to the bounding set. It is trivially easy to render your system useless by writing the wrong value there. But, with care, use of cap-bound can be put to good use in the creation of more secure systems.
Linux Trace Toolkit 0.9.0 has been announced. This toolkit allows the instrumentation of a Linux system such that all events which occur over a given time period can be recorded and examined. As such, it should prove to be a useful debugging tool for no end of system development tasks. The package includes a graphical front end for viewing of event traces and such. There is a lot to it - see the LTT home page for more information.
QNX filesystem on the way out? Here's a recent note to linux-kernel from Alexander Viro, who has done a lot of Linux filesystem work. Evidently the QNX filesystem is hopelessly broken in 2.3, and appears to be unmaintained. Unless something changes, QNX will not likely survive into 2.4. Thus, if you care about this filesystem, it's probably time to be thinking about how maybe you could help...
Other patches and updates released this week include:
Section Editor: Jon Corbet
December 2, 1999