If a must-have, must-know innovation exists for Linux's future viability, you might place all bets on Security Enhanced Linux. Vastly misunderstood and underrated, SELinux provides a marketing differentiator that could carry Linux deep into infrastructures that so far have shown lukewarm acceptance of the open-source operating system. SELinux transforms standard Linux from a cost-effective and secure operating system into a behemoth.

In December 2000, researchers at the U.S. National Security Agency (NSA) working with Network Associates and MITRE released a B1 Class operating system to the public known as SELinux. Although many Linux professionals have heard of SELinux, few recognize that its heritage reaches back to the work of David Bell and Leonard LaPadula, work begun in 1973. Bell and LaPadula's work helped define the criteria that make up the U.S. Government's Trusted Computer System Evaluation Criteria (TCSEC).

Four years after the release of SELinux, several Linux distributors, Red Hat, SUSE, Debian GNU/Linux and Gentoo Linux, finally have announced plans to support it.

As with many new technologies, a lack of easily digestible information created a barrier to understanding and using NSA's Linux. So when BillMcCarty's recent book, SELinux NSA's Open Source Security Enhanced Linux hit the market last month, I grabbed a copy. In all of his books, Bill explains the Linux security model in logically organized, simple and understandable terms. I zipped through his book and began working with SELinux immediately.

I found Bill's directions to be clear, following a step-by-step method of helping the reader gain knowledge and then helping him or her apply that knowledge. His new book helps you understand the SE Linux model, install the necessary components and troubleshoot problems that might arise. Add a nice section on administering SE Linux, and you have a complete manual to lead you into the realm SE Linux specialists. Although unusual, readers should find the standard body of information and knowledge required for SELinux in less than 200 readable pages.

I contacted Andy Oram, Bill's editor at O'Reilly & Associates, and arrange for an interview with the author. Like his book, Bill surprised me with with his vast knowledge and ability to articulate his subject in discernible ways.

Linux Journal: I read your book and came away excited about SE Linux. What inspired you to write it?

Bill McCarty: One explanation is I'm a writing addict; that is, one who writes compulsively. I've written more than a dozen technical books. On the other hand, I did have some quite specific reasons for writing about SELinux.

Apart from the time I spend writing, I teach and do IT research at a liberal arts university, Azusa Pacific University, in Southern California. My primary research interest is honeynets, a technology that lets us learn about the tools, tactics and motives of what I call "bad guys" and who are otherwise known as hackers, crackers, blackhats and so on (see www.honeynet.org). As a honeynet researcher, I see a lot of compromised systems, so I'm particularly aware of how dangerous our information superhighway has become.

I believe that, for Linux users, SELinux can reduce our computing risk. Just as automobile seat belts make us safer while driving, SELinux has the potential to make us safer while computing. SELinux won't prevent accidents, but it can greatly reduce serious injuries and fatalities.

LJ: Many people, myself included, believe that SE Linux is the future of Linux. Do you agree? What makes you feel that way?

BM: SELinux is now an integral component of several Linux distributions, such as Fedora Core, Gentoo and the beta release of Red Hat Enterprise Linux 4. I anticipate that publishers of other distributions will soon follow suit and that SELinux will become nearly ubiquitous. Given that, I'd argue that SELinux is the quite near future of Linux, almost the present rather than the future.

So, those who decide the contents of Linux distributions already seem to have concluded that SELinux is worthwhile. Yet, being of a cautious nature, I'm not satisfied that this one fact settles the issue. It remains to be seen whether users will seize the opportunity to use SELinux effectively. In some distributions, users must explicitly enable SELinux. In others, SELinux is enabled by default, but users have the option to disable it. The real litmus test of SELinux success is not the number of Linux hosts on which it resides, but the number of Linux hosts on which it's enabled.

By design, SELinux largely is transparent to the user. But, as with any relatively young software product, SELinux includes a few glitches, so those who want to use it effectively must learn a bit about it. Some folks prefer to avoid both problems and learning. When faced with even a minor problem, they figure out how to disable SELinux and do so. Others realize that the problem is merely a minor one and discover how to resolve or work around it. Fortunately, the Linux community consists primarily of folks who have an appetite and aptitude for learning and who are motivated to coax their systems [toward] optimal performance and security. I wrote my book to help these folks get past any minor problems that may arise in using SELinux and to help them use SELinux as effectively as possible.

LJ: The National Security Administration played a big part in creating SE Linux. Do you see this security model being deployed in the federal government? Where and when?

BM: As a California resident, I seem to be about as far removed from the US federal government as anyone in the forty-eight contiguous states can be. But, occasional trips to the East Coast and conversations with those more involved in Federal affairs than I am convince me that the federal government is aware of the potential inherent in SELinux and is moving expeditiously to capitalize on it.

The NSA, a Federal agency, has been--and continues to be--a resource for the SELinux community. It sponsored the theoretical research that produced the Flask security model underlying SELinux. And, they funded the initial development of SELinux. The NSA continues to host the Web site from which the reference implementation can be obtained. And, several principal SELinux developers, such as Stephen Smalley and James Carter, correspond on the SELinux e-mail list by using .mil e-mail addresses. And, the National Science Foundation awarded a substantial grant to several universities who plan to encourage and facilitate the use of SELinux within the academic sector, which has been castigated repeatedly for its allegedly lax computing security.

I have only limited awareness of specific applications of SELinux within federal agencies. Although I'd been aware of SELinux for some time previous, I first met folks actually working with SELinux at a NASA office, and I suspect that NASA's scope of SELinux use is significant. Even though security shouldn't depend solely upon obscurity, obscurity remains a useful security measure. I invite anyone who believes otherwise to post their passwords above their workstation .

So, being a believer in the incremental contribution of obscurity to security, I'd be a bit disappointed and upset if NASA and other agencies were vocal particularly about any security product or technology on which they depend, whether that's SELinux or something else. I think our interests are best served if potential attackers are left guessing what countermeasures their attacks may encounter.

LJ: Linux already has the concept of least privilege in its security model. Can you briefly explain how SE Linux adds to that concept?

BM: Hmm, I agree that knowledgeable Linux system administrators embrace and apply the concept of least privilege. But, I'm not so sanguine about the quality of Linux support for least privilege. The notion of root as the privileged user undercuts least privilege in the standard Linux environment. As soon as an intruder gains access to the root account, the game is over.

SELinux can impose the principle of least privilege on even the root user, enforcing policies that constrain what operations the root user can perform. Under SELinux, an intruder who gains access to the root account has indeed made headway. But, the intruder doesn't yet own the host. Every second the intruder is delayed from owning the host provides opportunity for the host's admin to detect the intrusion. And, every operation the intruder must perform in attempting to gain complete control of the host complicates the intruder's task and increases his risk of detection. Rather than the single strand of barbed wire provided by the standard Linux security model, SELinux provides a relatively deep mine field that a would-be intruder must transit quickly and quietly or suffer failure.

LJ: 0-day vulnerabilities are greatly reduced by SE Linux. How would you explain that to a corporate or government CIO in short sound bytes so he or she could understand it?

BM: I don't think I'd say that SELinux reduces 0-day vulnerabilities, so much as it reduces the consequence of such vulnerabilities. The vulnerabilities, which are present in the target programs, continue to exist. SELinux separates the target programs from the rest of the system. So, an attacker who uses a 0-day vulnerability to compromise a program doesn't gain a very substantial beachhold as a result of his success.

Here's how I'd put it to a CIO. Computer intrusions are in some ways like burglaries. You can't really hope to eliminate 0-day vulnerabilities any more than you can hope to equip your house with windows that are burglar proof. But, what you can do is put double-cylinder locks on all the interior doors. When a burglar enters by way of the open bathroom window, he won't quickly or easily find his way to the wall safe in the master bedroom's closet. Instead, he'd have to pick or break a whole series of locks. If the locks are properly installed and the doors are solid, they'd take time to defeat, and the intruder knows that he'd make a good deal of noise in breaking them. So, it's more likely that he'll take what he can from the bathroom and leave, hoping to find better loot elsewhere. You probably won't find it very bothersome to replace the spare toilet paper rolls the intruder steals. Certainly, you'll miss them less than you would the contents of your wall safe.

LJ: You listed some problems administrators would have with SE Linux policy files. You recommended using permissive mode to troubleshoot those problems. What do you think it might take for the Open Source community to provide mature templates? And, where can people go to assist?

BM: Good policies are not trivial to create. They require both considerable insight into the related program and extensive testing of the resulting policy. Those having programming skills are best qualified to undertake initial policy design and implementation. But, system administrators who lack or prefer not to exercise programming skills can help significantly by reporting problems to the SELinux mailing list or the mailing lists associated with their Linux distributions. Most policy problems are trivially fixable. But, policy developers can't fix problems of which they're unaware. It's most helpful when those reporting problems include related log entries, because these generally pinpoint the problem.

Using permissive mode is a helpful approach, because in that mode SELinux continues reporting problems after an initial hiccup. In enforcing mode, SELinux immediately prohibits the unauthorized operation, which may result in termination of the related program. A terminated program can't tell us what subsequent problems it might have encountered. So, fixing the revealed problems may not be sufficient to achieve a complete, correct policy.

LJ: Will RHEL 4 increase or speed up SELinux adoption?

BM: Based on the beta RHEL 4 release, I anticipate that SELinux will be enabled by default in the production release of RHEL 4. In that sense, SELinux adoption will increase dramatically upon release of RHEL 4, as already has happened as a consequence of its incorporation in Fedora Core 2 and 3. But, adoption may increase without users even being aware of SELinux. In one sense, this would be good. Many people would benefit from a painless, transparent mechanism that improves system security. But, so much more is possible using SELinux. I don't know how many people will be inclined to improve SELinux. But, because we're considering Linux users--who are extraordinarily curious and capable--I'm optimistic that the number will be large.

LJ: Why do you think other Linux distributions haven't embraced SE Linux?

BM: My own perception is that SELinux reached critical mass in terms of usable quality only about six months ago. Before that, a relatively high level of skill and motivation were needed to deploy and use SELinux successfully. That's now changed, and incorporation of SELinux into distributions has lowered the bar even further. So, my take is that six months isn't a very long time. I don't think that the absence of SELinux from some Linux distributions reflects negatively on either those distributions or SELinux. The proof of my pudding will come in perhaps another six months. By then, I'd expect the number of distributions that include SELinux to have increased substantially. I doubt that any leading Linux distribution reasonably can afford not to include SELinux within that time frame or soon thereafter.

LJ: Do you think people looking at a career move might consider SE Linux consulting? Is this the right time to go into that field?

BM: Not that I'm a marketing expert, but I don't believe the current IT climate is favorable to narrow specialists. I do think that SELinux [knowledge] could be a useful and profitable tool in a consultant's toolkit. In particular, developing SELinux policies for proprietary, in-house applications could turn out to be a significant segment of the Linux consulting market. But, I think that most consultants better serve their interests by having and offering a broader range of skills and products. So, I'd suggest that consultants develop an understanding of SELinux and offer related services to clients who might have interest. But, I don't suggest that consultants throw away their existing tools or scribble over the list of skills on their current shingle. For many consultants, business remains tight, so scope and flexibility are crucial to maintaining revenue.