SELinux

SELinux now enabled in AppArmor’s openSUSE

On Friday, Aug. 22, openSUSE announced that its newest version, 11.1, will support Security Enhanced Linux, or SELinux. Novell’s security tools, AppArmor and SELinux, have traditionally been considered intense rivals. In this interview, openSUSE’s Andreas Jaeger, Roman Drahtmüller and Matthias Eckermann discuss openSUSE’s support of SELinux.

OpenSUSE now has basic enablement with SELinux. That’s great for SELinux users now, but will openSUSE be able to integrate new patches for SELinux?

Andreas Jaeger : OpenSUSE is developed with a community approach; We are proud to have opened the openSUSE build service to the community, with the option to develop and package open source software cross-distribution.

As SELinux is a cross-distribution effort, we encourage members of the SELinux community to participate in the openSUSE build service: to develop, test-drive and integrate new user land patches and tools into openSUSE and other distributions using our cross-distribution service. This way, all distributions running with SELinux enabled in the Linux kernel will benefit.

Is support of SELinux indicative of a larger industry trend toward interoperability?

Roman Drahtmüller: Novell observes a tendency in the industry to increase the security value of a system by introducing additional controls beyond the scope of the application. This means the application is exposed to these controls but cannot change them.

In moving from AppArmor to SELinux, does a company sacrifice compliance benefits?

Drahtmüller: AppArmor profiles for application containment and confinement are comparatively easy to manage throughout an infrastructure. Creating them is a distinct, low-pain checkmark item. The same applies to evaluating log messages that record possible violation attempts against protected system services.

For customers, the transition to SELinux may need a change in thinking and architecture, but also allows for the definition of a complete policy in a system. It helps to disallow actions that are not subject to a defined policy. There are environments that require such a functionality — regardless of the cost associated with it — for compliance reasons.

We anticipate that customers with these requirements will aim for a SUSE Linux Enterprise operating system, as it targets the special needs of customers working in compliance-bound environments.

Security tools have created a tradeoff between capability (SELinux) and usability (AppArmor). Is Novell’s approach to this tradeoff changing with its basic enablement of SELinux?

Matthias Eckermann: As in earlier releases of our product, openSUSE 11.1 reflects our belief in the value of additional security mechanisms in the operating system. The benefit of such mechanisms is maximized if the configuration and administration is as transparent, straightforward and as easy as possible for administrators.

Security needs that aim toward mandatory access control, mandatory integrity control or even multi-level security require a suitable architecture. With the basic SELinux enablement, we will allow our partners and customers to use such an architecture to implement solutions that fulfill their specific needs.

Nevertheless, we want our users to be able to choose their own priorities between administrative effort and functional benefit.

What do you think? Leave a comment below or contact chunter@techtarget.com.

Great planning coincides Red Hat Summit, Celtics victory, CEO says

Red Hat CEO and President Jim Whitehurst began his opening keynote of Red Hat’s fourth annual Summit today by crediting event organizers for coordinating the Summit event with last night’s Celtics victory over the Los Angeles Lakers.

“We got everyone tickets for Game 7,” Whitehurst joked. “I wish we could get the Celtics red hats to wear in the parade.”

Whitehurst said that open source really is a business model where everyone wins by sharing innovation, which spreads the benefits of innovation and spares originators the cost of maintaining proprietary technology. He cited several examples where companies contributed innovations to the open source community that have led to major improvements. For example, a Canadian insurance company contributed what became JBoss’ Enterprise Service Bus and the U.S. government shared the development of what is now known as SELinux, he said. In addition, an innovative messaging protocol developed by JPMorgan is being tested now as part of Red Hat’s MRG [Messaging Real-time Grid] product, he said.

Contributions of innovations is a win-win proposition; the whole open source community benefits by incorporating and building on the improvements. But the contributors benefit too from lower support costs, he said.

The problem is that these are only a few examples; the vast majority of private development enterprise software is wasted, Whitehurst said, in urging attendees to promote open source and participating in community development.

Red Hat will launch more new products than ever this year, ensuring that its software and support will be better than ever, Whitehurst added.

“We are the leader in open source,” he said. “It’s who we are and what we do.”

However, leadership involves not just good software but also behind-the-scenes work to improve open source interoperability, like a recent lawsuit settlement that Red Hat negotiated to protect not only Red Hat but past and future users from litigation.

In his travels around the globe, Whitehurst said the most frequent customer complaint is that Red Hat isn’t always easy to work with when it comes to communications and recordkeeping. And Red Hat will be addressing that issue in the weeks and months ahead, he said.

So after a perfect Boston day of sunny skies and refreshingly cool temperatures, Red Hat attendees will be celebrating their adoption of open source software at a party in Fenway Park. Go Sox!

Novell slapped with suit for new mini-OS

Astrum Inc., a software security company in Carrollton, Texas, has filed suit against Novell Inc. Astrum claims that Novell violated its contract regarding development of the mini-operating system appliance that Novell launched last month. Novell’s JeOS or Just enough Operating System, is a miniature version of the SUSE Linux Enterprise OS, which was created to help independent software vendors develop or deploy new SUSE-based applications easier and faster.

Filed in U.S. District Court in Texas’ Eastern Division, the lawsuit contends that the two companies entered into a mutual nondisclosure agreement on Oct. 25, 2006, to develop the software appliance but Novell violated the agreement by revealing confidential information to partners and customers. Then, after the prototype was successfully tested in November 2007, Novell engaged rPath of Raleigh, N.C., the following April to create the appliances based on SUSE Linux Enterprise.

The suit alleged breach of contract, trade secret misappropriation, common law misappropriation, misappropriation of ideas and promissory “estoppel,” or broken promises.

The suit sees preliminary and permanent injunctions against Novell to stop downloads of its JeOS appliance as well as a related white paper and to halt the sale of appliances in the PCI industry. A jury trial was requested.

Ironically, the parties involved shared close ties at one time. Both Astrum CEO David Bunn and Patrick Cush, Astrum’s vice president of product development, are former Novell employees. In 2006, the same year Bunn was laid off from Novell, Bunn and some investors bought Astrum and then proposed the project soon after. Astrum also was an exhibitor at Novell’s BrainShare conference last March. Bunn has declined to comment on the lawsuit.

Kevan Barney, the acting director of Novell’s global public relations, said the company is “aware of Astrum’s claims and believes such claims are without merit. “Novell intends to aggressively defend against these claims,” Barney said.

Ubuntu’s Hardy Heron nests at Fox News

Ubuntu may not be a household word, but the increasingly popular Linux operating system is no stranger at Fox News. A Ubuntu blogger who complained that he couldn’t view video on FoxNews.com got a personal response from David Denis, Fox News Digital’s director of development. Denis not only went to the trouble to solve the problem (which actually stemmed from Fox’s video vendor, Maven Networks) but acknowledged the growing use of Ubuntu.

“Most of our developers actually run Ubuntu, so we’re definitely focused on correcting [the problem],” he wrote, according to the ERACC Web Log.

Martin Owens, the leader of the Massachusetts Ubuntu Local Community Organization, said, on the one hand, that he was surprised that Fox would allow its employees to use Ubuntu. On the other hand, technical people “are on the cusp of understanding what all this IT mumbo jumbo is about,” so it’s only natural that they would want to use Ubuntu’s advanced features at work, he said. Maybe the feedback from technical teams will convince the rest of the Fox gang to try it too, he added.

Move over, Windows … Ubuntu wants more room in the nest.

SELinux — is it *really* too complex?

I read a post this afternoon that surprised me a little, which is tough to do because I work on the Internet and I’ve basically seen everything humanity has to offer. Believe me, it’s not much.

What surprised me today is that the old axiom “SELinux is so difficult to use that most IT managers just switch it off” has bubbled to the surface again over at Kerneltrap.org.

The post at Kerneltrap is actually a snippet from a larger rant on the OpenBSD mailing list, which compares the security of SELinux to OpenBSD’s default security.

A thread on the OpenBSD-misc mailing list compared the security of SELinux in the 2.6 Linux kernel to what’s available in OpenBSD. The general opinion was that SELinux and its policy language are too complex, leading Damien Miller to note, “every medium to large Linux deployment that I am aware off has switched SELinux off. Once you stray from the default configurations that the system distributors ship with, the default policies no longer work and things start to break.” Ted Unangst summarized, “the problem with security by policy is that the policy is always wrong.”

I’ve written a few articles about SELinux over the past year and a half for this sole reason: complexity. I’m certainly no expert on the subject, but in 2006 and ‘07 I did get to hear from people at various Linux conferences and from interviews for other security stories that SELinux was a great piece of software — perhaps “too great.” As was argued above in the OpenBSD list, people were shutting it off because its NSA-powered muscles were breaking their systems. When that happens, you’ll find 9 times out of 10 an administrator will opt to shut the thing off and find another fix rather than invest the extra time and money, regardless of the features being promised him/her. So I started asking, “what’s being done? Who’s doing what?” and so on.

The folks at Red Hat were the most helpful, for obvious reasons (SELinux is baked into Red Hat Enterprise Linux), but I also interviewed a few SELinux experts for my research, including Karl MacMillan and Frank Mayer, co-authors of SELinux By Example. Mayer even wrote us a nice article on SELinux, called Five Ways SELinux may surprise you, that still does well traffic-wise on SearchEnterpriseLinux.com today. I also interviewed the guys in the trenches who had decided to shut the thing off and deal with it later.

What I discovered is that part of SELinux’s current dilemma is more easily fixable than the other, because it has nothing to do with technological chops and everything to do with public perception. Jim Klein, the director of information services and technology at the California-based Saugus Union School District, put it best: “The biggest problem for SELinux is mindshare,” Klein told me. “It developed a stigma early on due to the lack of tools for configuration and troubleshooting, which led people to simply turn it off.” Currently, Klein is one of the many IT guys who has the SELinux switch in the “off” position.

But Red Hat was ready for that, or so it seemed. At the Red Hat Summit in May their SELinux guru Dan Walsh was beating the setroubleshoot tool drum as proof that his developers were listening and SELinux was turning a corner towards simplicity. Also known as SELinux Troubleshooter, setroubleshoot is a tool that watches the audit log files for access vector cache (AVC) messages and send reports to the IT manager when things go wrong, right or whatever. Walsh said SELinux has a new GUI in RHEL 5 to assist in management, as well as a set of configurable Booleans (read: if, then statements) that allow IT managers to modify network ports, file labeling and event user mappings. That particular session was one of the more packed ones I attended in San Diego that week. Does that mean anything in particular? Not really, as security is always popular topic, but it was interesting given what’s still being debated today.

As Red Hat talks GUIs and tools and setroubleshoot (oh my!) those crafty OpenBSD guys are ready with a pithy retort (or is that snark?):

If the policy language was halfway sane then this wouldn’t be so bad - a skilled administrator could adjust the policy. Unfortunately:

1) skilled administrators are hard to come by, and their time is usually better spent *not* tweaking brittle mandatory access control policies

2) the SELinux policy language is nowhere near sane.

OpenBSD’s systrace suffers from #1 - it is a generic problem with these sorts of access control mechanisms, and it is one reason why it has never been enabled by default. The brittleness is a real problem - I use systrace for a few things and often need to update my policies because of software upgrades or libc changes. Oh, and “skilled administrator” means someone deeply familiar with the Unix system interface - not a just a graduate of certification course de jour.

The Linux solution to #2 seems to be to add various wizards and other abstraction between the administrator and the policy, rather than tossing the horrid mess and replacing it with something more comprehensible.

What this all means to me is if we can find similar thoughts being shared outside of an OpenBSD mailing list (where Linux or SELinux surely don’t have the home field advantage they’re used to in, say, Linus Torvalds’ backyard), we might be onto to something. That something? That SELinux should in fact be turned off indefinitely until this complexity issue is resolved.

Until then, however, I think we all should probably look into some advice I found in the Kerneltrap comment section:

If I wanted a fair comparison of OpenBSD and SELinux, the last place I would ask would be the openbsd-misc mailing list.

Could be good advice.

Related info: Our site expert James Turnbull has a brief comparison of SELinux and AppArmor (the latter being what Novell SUSE has to offer).

A step-by-step guide to building a new SELinux policy module

Are people still terrified of SELinux? Of its complicated policy module creation and rules by the fist mentality over Linux systems? Oh right, they are. That’s why over the past year every conference I’ve attended had a session about SELinux and how much easier it is to use than it was last year.

Red Hat Magazine editor and SELinux guru Dan Walsh:

“Who’s afraid of SELinux? Well, if you are, you shouldn’t be! Thanks to the introduction of new GUI tools, customizing your system’s protection by creating new policy modules is easier than ever. In this article, Dan Walsh gently walks you through the policy module creation process.

A lot of people think that building a new SELinux policy is magic, but magic tricks never seem quite as difficult once you know how they’re done. This article explains how I build a policy module and gives you the step-by-step process for using the tools to build your own.”

Hmm, magic. Good one. I think when SELinux does work as advertised you’d be hard pressed to find a Linux administrator who doesn’t attribute some of that success to the Black Arts.

Does SELInux work? Is it really powerful? You bet it is, but maybe *too* powerful since users are routinely switching it off when it doesn’t allow them to do anything with their own systems.

Luckily for you RHEL users out there, Walsh goes beyond magic tricks and lays out a step-by-step explainer for SELinux policy module creation in his latest article at Red Hat Magazine. He advises users to start small, use new tools like polgengui, and then he just goes crazy with the steps (complete with screen grabs for the visual learners, like myself).

It’s a good read, and if my experience with Walsh is any indication (I’ve seen his presentation at the Red Hat Summit), there will be more to follow.

Slashdot readers dish out SELinux advice

There’s some cool commentary going on at Slashdot this morning about SELinux. And wouldn’t you know it, it’s about one of articles here at SearchEnterpriseLinux.com.

The article was a mash-up of some stuff I had left over from May’s Red Hat Summit in San Diego, an interview with author and SELinux expert Frank Meyer, and an exchange with our new blog contributor Jim Klein, the the director of information services and technology at California-based Saugus Union School District. (Link: With RHEL5, Red Hat goes to bat for SELinux)

The comments at Slashdot are arriving from readers on all sides of the SELinux aisle. Some agree that SELinux has come a long way and that people like Red Hat’s Dan Walsh are right to ask it be turned on all the time; others agree with the assertion that its already been typecast as too complex; while some fall in the middle asking for more advice. Oh, and some just plain hate it.
Here’s some of that straightforward advice, from Slashdot reader BigBuckHunter:

Step 1: Install RHEL, disable SELinux
Step 2: Install and configure your stack (apache, jboss, tomcat, mysql, whatever)
Step 3: Enable permissive mode, light up the stack, watch logs
Step 4: Tweak the rules, repeat step 3 until the logs are clean.
Step 5: Enable Enforcing Mode
You can now rest a little bit easier knowing that you have SELinux enabled. The only drawback is that you sometimes have to repeat the process as new versions of your stack are released (mysql, jboss). It’s basically a monthly process.

This is not the last of our coverage on SELinux. Watch for more as it continues to mature.