The Linux Hardware Abstraction Layer, or HAL, is a much friendlier computer tool than HAL, the bipolar computer in the movie, "2001: A Space Odyssey". While HAL left its users lost in space, Linux HAL helps Linux desktop users get connected hard-to-handle hardware devices.
In other words, Linux HAL opens the pod bay doors.
In many ways, a Linux business desktop environment presents a far different landscape than a home desktop environment, primarily in regard to the divergent multiple and single-user schemes each one typically implements. Despite these differences, the emerging Linux HAL (henceforward referred to only as HAL) provides one common thread that offers basic functionality from which both camps can benefit.
As some may already know, the Linux Hardware Abstraction Layer, or HAL, made its debut with Fedora Core revision 3, and builds upon the D-BUS messaging subsystem to enable direct application-to-application communications. Together, the HAL and the D-BUS subsystem create an intermediate layer between the Linux kernel and user-mode applications. They form a single-mapping messaging framework for device objects and end-user applications.
To end-users and user-mode application developers, this is a remarkable thing. It adds welcome transparency to the way hardware devices -- particularly hot-pluggable storage -- are handled and creates uniformity among the APIs that accessing them from user-mode. Overall, this translates into greater usability and improved user-friendliness for user-mode applications across the board.
HAL provides uniformity and integration with devices in the user-mode arena, but it also enables the system to profile and police application behaviors -- exclusively within the native SELinux security policy context -- using a tool called the PolicyKit.
HAL and the PolicyKit can work together cohesively, when integrated by a capable system designer. Essentially, you can enforce a per-user policy to manage the behaviors of applications that interact with devices at the desktop level—a technique that's well-suited to controlled environments or public terminals (such as kiosks or public-access PCs) exposed to potentially hostile or malign users.
Although this technology is still in its infancy, Fedora Core revision 5 lays a foundation sufficient to profile unprivileged actions for a handful of devices.
According to HAL lead developer David Zeuthen, Fedora Core 5 implements methods that enable coarse-grained controls over laptop displays, power management, and local and network storage mountsIt also ships with a default policy that governs most aspects of Gnome's power management utility. This lets system administrators exercise greater control over workstations, kiosks, and terminals -- to lock out USB devices; to prevent abuses associated with plug-and-play hardware; to prohibit unauthorized mounting, un-mounting or manipulation of storage drives; and to protect systems against end-users who might attempt to modify existing control settings to take advantage of (or create unnecessary problems for) other users.
Some of this capability is exposed in the GNOME power-manager facility. It permits administrator to establish consumption and usage requirements for laptops and desktops—and to manage them dynamically. Zeuthen also provides the following pseudo code to illustrate how easy it is to write such system-wide policies, as shown in the following code fragment:
[policy-service]
exec=/usr/bin/my-power-manager-when-no-one-is-logged-in
id=PowerManagement
per_console=false
The above snippet describes a situation when no user is logged into a desktop, which allows the default policy to override what would otherwise apply based on whichever the user logged-in most recently. Also, a per_console directive allows policy coverage to extend to all user consoles, even when user-switching occurs.
Zeuthen's basic concept is that such configuration tools and should be easy to use, first and foremost, as well as functionally correct and accessible to anyone. That's a mindset rarely encountered in security instrumentation.
When developing PolicyKit, Zeuthen researched the few available tools that offer the same level of functionality. All operated on the same flawed principle: they use super-user privileges to get any work done. It is this inherent security risk that motivated him to launch the PolicyKit project.
PolicyKit represents a nice step in the right direction in that it provides a uniform, transparent, granular application behavior profile with system-wide effect, where all functionality converges neatly within an intuitive, user-friendly interface.
Right now, the PolicyKit facility still lacks the polished finish of production software, but it is worth watching. When it's ready for prime time in the next year or two, you'll want to give it a try.
About the authors: Ed Tittel is a full-time freelance writer and trainer based in Austin, TX, who specializes in markup languages, information security, and IT certifications. Justin Korelc is a long-time Linux hacker who works with Ed, and concentrates on hardware and software security topics. Together, both contributed to a recent book on Home Theater PCs; right now, both are busy at work on a book about the Linux-based MythTV environment.
