Trusted operating systems have been used for some time to lock down the most sensitive of information in the most sensitive of organizations. But with security concerns rising and changing by the hour, its now a matter of trust for any organization looking to tighten its computing ship.
Several vendors, including Red Hat, Sun Microsystems and Novell, are responding by adding and/or improving trusted elements in their operating system offerings.
Operating systems are designed to do what theyre told, and we tell them what to do by running applications. However, whether through bugs or malicious exploits, applications can tell an operating system to do things that no one intended or wanted it to do—at least no one authorized to do so.
Todays mainstream operating systems are trusting—they trust that the applications running on them are doing what users intend the apps to be doing. These operating systems havent been designed to limit applications from doing more than theyre intended to do.
This can be bad enough when youre talking about individual users, whose privileges can be limited enough to ensure that they cant modify system files.
But many applications, including many server apps, require some root-level rights to do their jobs in the first place. Once subverted, one of these applications can be wrangled into causing all manner of mischief (and into covering its tracks, to boot).
Enter trusted operating systems.
Rather than trusting the apps they host, trusted operating systems include functionality thats intended to restrict the damage an exploited application can wreak by limiting it to only those capabilities and rights it requires to get its job done.
While trusted operating systems have a lot to offer, theyre famously tricky to manage—with tight application control comes plenty of room for incompatibility.
As a result, trusted operating systems have tended to occupy a slender niche and, in turn, have lacked the full attention of operating system vendors and of the software and hardware vendors whose certifications and support are critical when working with products that are challenging to manage.
However, things have been changing during the past few years, as makers of general-purpose operating systems have been pushed to include trusted functionality in their mainstream products.
Most notably, Sun, Red Hat and Novell are each shipping enterprise-class operating systems with built-in trusted functionality available out of the box—specifically, provisions for finer-grained access controls.
Accordingly, enterprises have more opportunity than ever to defend themselves from software exploits and bugs by relying on operating systems that view the applications they host with a healthy dose of skepticism.
eWEEK Labs has put the application lockdown options from Sun, Red Hat and Novell through their paces, installing and evaluating this lockdown functionality in the context of securing the Apache/MySQL/PHP-based Mediawiki Web application in hopes of providing a starting point for eWEEK readers own evaluation of these technologies.
Sun and Solaris 10
Solaris 10 ships with a bolstered access-control scheme, called Process Rights Management, that extends the standard Unix permissions under which processes have to run as root with a set of privileges that administrators can parcel out to processes as need be.
While Solaris 10 makes it possible to get rid of the superuser account, it doesnt do so by default (to preserve backward compatibility).
However, rather than break privileged rights into all or nothing, in Solaris 10, the privileged rights are broken into all or basic—with basic being a handful of specific privileges that together represent the rights that a regular Unix user would possess.
Unlike with a standard Unix or Linux system, however, administrators can use Solaris 10s tools to add rights to a process beyond the basic set, as well as remove rights from the superusers “all” set.
There are four ways to add and drop processes in Solaris.
First, there is the ppriv command-line utility, with which you can view or modify the privilege set of a particular process. This command is handy for debugging system privileges, and by running “ppriv -lv” you get a nice list of the 50 or so permissions covered under Solaris rights scheme.
Another route to fine-tuning the rights with which applications run is to use Solaris new Service Management Framework. Following a tutorial on Suns site, eWEEK Labs configured an Apache installation from The Apache Software Foundation to start as a non-root user. We then added the rights that Apache required to our non-root-users basic privilege set.
You can also adjust the rights with which users and applications run in Solaris 10 by creating roles with the needed range of rights. Roles in Solaris are akin to user accounts, but they lack log-in rights; users must be logged in to assume a role.
Finally, Solaris 10 offers APIs for building privilege-aware applications—those that can assume and drop the rights they require from the set of privileges theyre accorded by the system administrator.
With the variety of methods available for using it, and with the provisions throughout Solaris 10 for maintaining backward compatibility, Process Rights Management definitely takes some getting used to.
In our testing so far, weve found Solaris Containers feature to be a much simpler-to-approach means of process confinement, although you can use Containers and Process Rights Management together. While Red Hat and Novell are each working on providing similar functionality through Xen virtualization, the Solaris approach is much leaner, more manageable and, most important, more mature.
The trusted functionality in Solaris 10 is descended from Suns Trusted Solaris, the companys stand-alone trusted operating system.
Marking the completion of the merging of the Solaris and Trusted Solaris products, Sun plans to release this summer Solaris Trusted Extensions, a set of add-on components for Solaris 10 that will enable organizations running Trusted Solaris to move to Solaris 10.
These extensions will add to Solaris the multilevel security functionality of Trusted Solaris, along with desktop integration that will allow organizations to, for example, keep classified data displayed in one window from being pasted into an unclassified document in another window.
Next Page: Red Hat and SELinux.
Red Hat and SELinux
This kind of integration in Trusted Solaris required COSEs (Common Open Software Environments) crusty CDE (Common Desktop Environment), but Solaris Trusted Extensions will leverage GNOME, according to Sun officials.
Red Hat and SELinux
Red Hat has built support for mandatory access controls into its RHEL (Red Hat Enterprise Linux) and Fedora Core Linux operating systems by implementing SELinux (Security-Enhanced Linux), a set of Linux kernel components and user space software developed initially by the National Security Agency.
SELinux provides fine-grained control over everything that happens on a system by checking requested activities against policies that describe explicitly the privileges available to each user and application on the system.
Many of the core applications on Red Hats distributions have been modified to work with SELinux—the “ls” command, for instance, was modified to display the security context of file objects when paired with the “-Z” argument on the command line.
On a machine thats completely locked down by SELinux, there must be policies for every application because anything that is not allowed is, by default, prohibited. This turned out to be a problem when Red Hat was testing Fedora Core 2, its first distribution to include SELinux.
The Red Hat team found that Fedora Core 2 worked fine out of the box, but, once users began configuring their Fedora boxes for their own needs, the new security framework caused so many compatibility problems that Red Hat shipped Fedora Core 2 with SELinux turned off by default.
In Fedora Core 3, Red Hat modified SELinux to allow for both “strict” and “targeted” policies. The strict policy offered a complete lockdown, while the targeted policy enforced SELinux controls only on a set of typically network-facing and therefore more vulnerable services.
Red Hats distributions released since Fedora Core 3—including RHEL 4—have shipped with the SELinux targeted policy on by default. And with each new release, Red Hat has expanded the number of services covered under the targeted policy. (RHEL 4 may be run under strict policy, but doing so with support requires a separate services contract, according to Red Hat officials.)
In the recently shipped Fedora Core 5, which will form the basis of the forthcoming RHEL 5, Red Hat has introduced two new SELinux features intended to improve the state of policy writing and deployment. (For eWEEK Labs review of Fedora Core 5, see “Fedora Core 5: Shape-shifter” at eweek.com.)
Fedora Core 5 includes policy modules, which, like Linux kernel modules, may be plugged into a systems SELinux policy. (In the past, policies had to be compiled into a systems master SELinux policy.)
This, along with the introduction of a reference policy on which other SELinux policies may be based, should help make the policy-writing process more structured and, hopefully, simpler for the larger community to participate in.
Both policy modules and reference policy are the work of Tresys Technology, a company that specializes in SELinux policy management and that has built most of the open-source policy tools that ship with Red Hat and other distributions that implement SELinux.
Tresys has recently completed a project with IBM in which it developed a means for creating SELinux policies to govern IBM WebSphere applications that span multiple RHEL servers. The tool can take a WebSphere application config file and generate a policy to limit, for example, member servers to communicating only with machines described in the configuration.
However, as the list of services covered under the targeted policy grows, so, too, grow the risks of software incompatibilities. Weve noted quite a number of these snags reported on product support forums and recently had to work around a compatibility issue with Samba during our QCD Admin review. (See “QCD weaves Linux admin into Windows” at eweek.com.)
While SELinux has gained a good deal of mind share with Red Hats backing and with the distinction of being the only mandatory access control scheme thats included in the mainline Linux kernel, third-party software vendors frequently recommend simply disabling SELinux to deal with these incompatibilities.
As implemented in Red Hats distributions, SELinux enforcement may be disabled only for particular targeted services, and most of the covered services offer a handful of Booleans to turn specific policy elements on or off.
However, policy creation and management remains the biggest knock against SELinux so far: While conceptually fairly simple, SELinux policies are rather long and involved.
In our testing with Mediawiki, Fedora 5s built-in Apache policy didnt get in the way and required almost no effort to employ. Modifying that policy, however, would have required more time than with Novells AppArmor or Suns Process Rights Management.
Red Hat officials have said they hope SELinux will become a standard among Linux distributions and that, in time, SELinux policy writing will be embraced widely enough to become a standard part of the Linux software development and packaging process.
Next Page: Novell and AppArmor.
Novell and AppArmor
However, the Linux community isnt there yet: While most significant distributions do offer SELinux packages, only Red Hat enables the framework by default.
Whats more, Novells SUSE Linux—which, next to Red Hat, enjoys the most prominence among enterprise users—has started down a separate, and incompatible, path for application lockdown.
Novell and AppArmor
Last year, Novell purchased Linux security vendor Immunix, along with the companys AppArmor application containment product.
AppArmor had been available as a proprietary add-on for Novells SLES (SUSE Linux Enterprise Server), but, after completing the Immunix deal, Novell released the software under the GNU GPL (General Public License).
Novell is now working to submit the newly freed project for inclusion in the mainline Linux kernel, where it would join rival SELinux as an application lockdown option for Linux.
Like SELinux, AppArmor plugs into the Linux kernel through an interface called LSM (Linux Security Modules).
When Red Hat first sought to submit SELinux for submission in the kernel, Linus Torvalds and other kernel developers demurred from crowning a particular security framework as the kernels one true path to mandatory access control and called for a generic mechanism through which multiple frameworks could connect—hence, LSM.
Red Hat and Immunix each contributed to LSM, which made its debut in the 2.6 kernel release.
However, while SELinux and AppArmor plug into the kernel in a similar way, the two systems take separate approaches: Where SELinux depends on object labeling, AppArmor controls are based on path-name locations.
For instance, when we created an AppArmor profile to contain the Apache service on our OpenSUSE 10.1 RC3 system, we began by specifying for AppArmor “/usr/sbin/httpd-prefork,” the Apache binary on our test system.
From there, AppArmor went into a learning mode, where it monitored the files that Apache read, wrote and executed, along with the POSIX capabilities that the service called on as we started Apache, interacted with our Mediawiki test site and shut down Apache.
Next, AppArmor stepped us through the actions that Apache had taken, asking us whether each should be allowed in our profile.
In the case of our Mediawiki application, AppArmor also gave us the option of enabling its “changehat” capability.
That is, when Apache interprets PHP scripts, AppArmor can switch to a separate profile for the PHP operations, rather than execute those operations under the same profile as the rest of Apache. AppArmors changehat feature also works with Apaches mod_perl facility.
AppArmor hangs its hat on ease of use, and, while rolling our own profiles wasnt as easy as using the premade policies that Red Hat ships with SELinux, doing it ourselves in AppArmor wasnt much tougher.
And, when dealing with an application for which theres no existing policy or profile, its no contest—App-Armor makes policy creation much simpler.
AppArmor ships with a complement of premade profiles for common network-facing services. Whats more, while we had to really pore through the source of SELinuxs policies to get a direct look at its rules of enforcement, AppArmor profiles are significantly shorter and easier to read.
The AppArmor approach delivers a smaller range of potential functionality than SELinux: AppArmor does not set out to lock down the entire system, as SELinux and a strict policy can, and AppArmor does not offer a route to multilevel security, as SELinux does.
Novell officials have said they are looking for a multilevel security solution that could plug into the kernel via LSM, function alongside AppArmor and exhibit ease of use similar to that of AppArmor. AppArmor also lacks SELinuxs capacity for implementing role-based access.
We could, however, use AppArmors trait of interpreting a hard link to an application as a separate entity (and, therefore, a candidate for its own profile) to create a rights-limited version of the bash shell. We could then assign this shell to a user to provide for some administrative privileges without giving up full root access.
Its only been since January that AppArmor has been licensed under the GPL, so, while we can test the softwares effectiveness in the SLES 9 and OpenSUSE 10 and 10.1 distributions on which its now available, its too early to see whether AppArmor will take off in other Linux distributions.
AppArmors pedigree stretches back a bit through Immunix, but the softwares previous proprietary licensing has retarded its spread.
Novells AppArmor team is seeking involvement from other major Linux distributions, such as Fedora, Debian and Gentoo. However, with current Linux access-control efforts spread among SELinux and other projects, including GRsecurity and RSBAC (Rule Set Based Access Control)—neither of which weve tested yet—Novell may have to work hard to win converts.
Senior Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.
What about Microsoft?
Four years ago, Microsoft laid out an ambitious plan for building an NGSCB (Next-Generation Secure Computing Base).
NGSCB was to be a trusted computing environment extending from motherboard-embedded security chips, through the Windows kernel and out to the application windows and input peripherals with which users interact with the system.
As a major player in the server space, Microsoft should offer the sort of mandatory access controls were beginning to see in Linux and Solaris. For now, though, the bulk of Microsofts privilege management is centered on the desktop.
* Reduced rights for Internet Explorer IE doesnt require all the rights of a limited user, let alone an administrative one, to do the work of rendering Web pages. In Vista, IE will run by default with less privilege rope with which to hang itself (and the system as a whole).
* A Vista for nonadmins Perhaps its silly to worry about limiting applications to the fewest privileges they require when, according to Microsoft officials, the difficulty of running current Windows versions with appropriately limited rights leads about 80 percent of business users to run as admins—a management gap that Vista should help patch.
* Virtualized system file stores If you cant control exactly what a particular application is allowed to do, you can at least issue it a safer sandbox in which to run. Vista will let applications that want to run as administrators modify system files and registry keys, but do so in a branched-off, virtualized area.
* Still hankering for NGSCB? Microsofts NGSCB developers are now called the System Integrity Team, and they have a blog at blogs.msdn.com/si_team/default.aspx.
