REVIEW: Red Hat Fedora 12 Beta Makes Progress on System Privilege, Virtualization Fronts

Fedora, Red Hat's leading-edge Linux-based OS, has hit a beta milestone. eWEEK Labs' tests show that Fedora 12 will provide the latest and greatest versions of popular open-source applications, as well as features that strengthen not only Fedora but also Linux distributions in general. In particular, Fedora 12 advances the state of Linux system privilege management on multiple fronts and exhibits continued progress in virtualization.

Red Hat's leading-edge Linux-based operating system, Fedora, hit a beta milestone this week on the way to its Version 12 release. As with Ubuntu Linux, which recently underwent a beta release of its own, Fedora 12 will be packed with the latest and greatest versions of popular open-source applications, such as the productivity suite, the Firefox Web browser, and up-to-date releases of the GNOME and KDE desktop environments.

For a look the Fedora 12 beta in action, check out this eWEEK Labs slide gallery.

Beyond these typical Linux updates, the updates that have caught my eye in this version deal with strengthening the core of the distribution and of Linux distributions in general, as Red Hat's open-source innovations trickle downstream into other Linux-based operating systems. In particular, Fedora 12 advances the state of Linux system privilege management on multiple fronts and exhibits continued progress in virtualization.

System Privileges

One of the first Fedora 12 enhancements to jump out at me was the distribution's new capability for sandboxing potentially untrusted graphical applications with SELinux. The new feature, called sandbox -X, provides graphical applications with a temporary environment to run in that's walled off from the rest of system.

For instance, on my test machine, I created a wrapper script for Adobe Reader (a frequent target of malware purveyors) that would launch the application within an SELinux sandbox. I could view my document normally (more or less, I experienced frequent Reader crashes during my tests, with or without the sandboxing), but could not browse my file system or reach the network. If I wanted to extend Internet access to my sandbox--to test a Web browser, for instance--I simply appended "-t sandbox_web_t" to my command to allow for the access.

For now, sandboxed applications launch in windows that cannot be resized, and not every application I attempted to sandbox worked properly. Firefox, for instance, launched without issue, but Google's open-source Chromium browser crashed immediately upon launch.

Moving forward, I'll be interested to see whether and how the Fedora project integrates sandbox-X with the rest of the distribution. If nothing else, the feature is a good example of what can be done with SELinux. For more information on sandbox -X, check out this blog post from Red Hat's Dan Walsh.

SELinux provides Linux with a scheme for mandatory access control, where the only rights that users or processes enjoy are those explicitly granted. In Red Hat and Fedora systems, SELinux usually operates under a targeted policy, where only specific parts of the system are controlled so tightly. The rest of these systems are bound by the traditional Linux DAC (discretionary access control) system.

In Fedora 12, this DAC scheme becomes more granular, with new work around limiting the privileges of processes that have previously run with all-powerful root privileges. The concept of "capabilities" enables applications that require certain root privileges to run with only those rights.

So, where SELinux works to limit the range of what applications are allowed to do, capabilities allow applications to request fewer rights in the first place. The capabilities work in Fedora 12 taps a library called libcap-ng that is meant to simplify the capability-dropping process for application developers. For more information on libcap-ng, check out this writeup from Red Hat's Steve Grubb.

A third privilege management enhancement coming in Fedora 12 comes in the form of a rewrite of the PolicyKit framework for granting system users particular elevated rights--such as the right to modify date and time information, create and modify user and group settings, or install software packages on a machine.

The current version of PolicyKit--which ships on Red Hat and Fedora distributions, as well as on Ubuntu, SUSE, and other distributions--doesn't lend itself to integration with networked resources such as directory servers, a major limitation in managed deployments.

The version of PolicyKit that ships with Fedora 12, while still implemented for storing its policies locally, has been reworked to allow for future directory integration--a major gain not only for Fedora but for Linux distributions in general. For more information on PolicyKit, see this reference manual for the project:


No new Fedora release hits the streets without a handful of new virtualization enhancements, and Fedora 12 is no exception.

In this release, one of the most compelling virtualization features is the system's support for Kernel Shared Memory, or KSM, a recent addition to the Linux kernel that enables applications to identify and share duplicate memory pages. In conjunction with Fedora's KVM hypervisor, KSM promises to boost virtual machine density on a given host by enabling administrators to overcommit memory without requiring that VMs swap to disk.

I tested KSM out by creating a couple of Ubuntu 9.04 VMs with 1GB of RAM apiece and a Windows 7 VM with 2GB of RAM. Together, these VMs laid claim to the bulk of the 4GB of RAM available on my test Fedora 12 system.

When I switched KSM on, I watched the memory usage on my test machine fall, fairly quickly, from 3.1GB to 2.1GB as my system identified and merged duplicate memory pages. I want to see KSM in action on a more realistically outfitted system, but I'm impressed the capability as I've seen it so far.

Beyond KSM, I'm pleased to see that in Fedora 12, KVM will support hotplugging for virtual network adapters, and will present guest machines with an emulated hardware platform that remains consistent across upgrades of the hypervisor. Linux OSes tend not to care when hardware is changed underneath them, but this can cause problems with Windows. I've experienced broken Windows VM installs following KVM upgrades, and I welcome this improvement.

Executive Editor Jason Brooks can be reached at