Linux in Government: Security Enhanced Linux - The Future is Now

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.
Interview with Bill McCarty
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.

Tom Adelstein lives in Dallas, Texas, with his wife, Yvonne, and
works as a Linux and open-source software consultant with
Hiser+Adelstein, headquartered in New York City. He's the co-author of
the book Exploring the JDS Linux Desktop and the
upcoming book Essential Linux System
Administration, published by O'Reilly and Associates. Tom has
written numerous articles on Linux technical and marketing issues as a
guest editor for a variety of publications.