Red Hat and SELinux

 
 
By Jason Brooks  |  Posted 2006-05-14 Email Print this article Print
 
 
 
 
 
 
 


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.)

Click here to read more about the diverse and complicated world of operating systems. 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.



 
 
 
 
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel