Again, apologies for the much delayed posting.  Finals together with the sluggishness of my backup computer made me unable to write this until now.

For those who don’t remember, we are in the middle of a series on what interesting developments and capabilities are ongoing within the Free Desktop to improve its fitness for both personal and enterprise usage.

Infrastructural Enhancements

This category of purely under-the-hood work is not immediately obvious and thus is often under-appreciated, but yields many useful improvements to the Free Desktop.

One notable entry here is automatic code parallelization in GCC (the main compiler on Linux) through Graphite, which should lead to significant performance improvements for all programs on computers with multiple processing cores.  Of course, the scope of what can be done is limited due to this sort of conversion requiring a higher-level view of what a block of code is meant to do, but nevertheless this is very much a welcome feature that will keep our beloved compiler in line with the current state of compiler technology.

Filesystems have always been an area of interest for the Free desktop; from the plain-spoken and default ext3 to the fast ReiserFS and SGI XFS, Linux especially has always had a variety of powerful filesystems available for any task. The march of progress has thankfully not left this critical job by the wayside.  ext4, the successor to ext3 featuring much improved performance through more flexible filesystem clustering through extents, and new features such as defragmentation support and checksumming of filesystem journals for increased reliability became stable in Linux 2.6.28.[22][23] Fedora 11 is going to include it included by default, which should come as either a pleasant or a terrifying prospect depending on one’s view on stability.[24] I’d say that I’m psyched, but I’m using it right now on my Arch Linux installation so such a statement would be misleading.

However, by the ext4 project leader’s (Theodore Ts’o) own admission, ext4 is not revolutionary enough.[25] The next major filesystem on the horizon is btrfs, designed to overcome many of the limitations of ext3 and ext4 in filesystem size and administration.[26] Among the interesting features it will bring will be transparent checksumming and compression for files, defragmentation and filesystem checking while the filesystem is mounted, and more sophisticated data striping.  If you’re keen to try it out, it should be included with Fedora 11, but be warned that the filesystem format is not yet stabilized or optimized and thus your data may be prematurely ended.[27]

Security

The infamous security framework soap opera is still going on, of course, with the usual politics and petty bickering within the Linux kernel development community.  Although the free desktop takes much well-deserved pride in its security, the Unix-like user-group-other security model (Discretionary Access Control, or DAC) traditionally used for managing permissions has proven to be both insecure and distinctly un-Unix-like.  Not only was it crafted before any concept of wide networking had really been established, but it also far too permissive and course-grained in its management.  Hence the need for a new security system that builds on top of the traditional model; there are many competing modules alive in the ecosystem, but it remains to be seen which (if any; after all, FLOSS is all about choice) will prevail.  An important thing to be aware of within this realm is the LSM, or the Linux Security Modules; a common Mandatory Access Control (MAC) security framework API within the kernel.

POSIX File Capabilities, while not strictly a security framework, are a minimalistic approach to security available since Linux 2.6.24.  Basically, they use the extended attribute system of modern filesystems such as ext3, ext4, btrfs, etc. to allow a program to do tasks that would traditionally require root permissions.  Far short of being a clone of the classic SETUID bit that forces a program to be run as root (an over-simplification), it instead limits what a program can do to the minimum that is needed.  The implications of this are invasive and far-reaching; for instance, using file capabilities it is no longer necessary to be root in order to burn an optical disk.  LWN as always has a good read on the topic.

SELinux (Security Enhanced Linux) is another security framework, only instead of merely being an extra set of permission bits it is a full-blown MAC solution.  Developed by the National Security Agency in 2000, SELinux was the first major security framework available for Linux and is now used most notably by Red Hat and Fedora.  Although it is generally considered quite secure because it uses an inode-based system instead of filenames (avoiding issues of different restrictions referring to the same file), it is also notorious for being a nightmare to configure.[28]

AppArmor is the main competitor to SELinux, developed originally by Immunix but later released and maintained by Novell after they perchased the former.[29] It is currently used by most notably by OpenSUSE and Ubuntu, presumably due to its ease of configuration compared to SELinux.  However, it is considered less secure due to its reliance on filenames instead of filesystem objects, and thus there has been a great deal of controversy both petty and significant to the point that Linus Torvalds himself has had to step into the fray despite his self-proclaimed disinterest in security frameworks.[28] Like SELinux, it is a MAC security framework using LSM, but unlike it, AppArmor has failed to be merged into the mainline kernel tree due to both technical troubles and political infighting.[29]

SMACK (Simplified Mandatory Access Control Kernel) is a much more recent entry into the security game available since Linux 2.6.25 that promises drastically simpler configuration at the cost of less power and capabilities compared to SELinux.  In addition to eased configuration, it apparently also uses a hybrid approach to the inode/path debate.[30]

Lastly, TOMOYO is the latest entry to this… active… environment of security frameworks.  It is not yet available in a stable kernel release, but should be available in Linux 2.6.30.  Much like AppArmor, it uses pathnames as its basis for handling files, but among other things is designed to be more robust by working around weaknesses in LSM allowing more intellegent handling of file objects.