Special Offers

Feature: Linux

Linux kernel to have NSA inside?

- By Joab Jackson -
Later this month, when Linus Torvalds and the other movers
and shakers gather for the Linux
kernel summit to map out the development course for
Linux kernel 2.5, they'll be hit with a proposed
modification from an unlikely party -- the U.S. National Security Agency.
There, Peter Loscocco, of NSA's Information and Assurance
Research group, will propose a
mandatory access control (MAC) architecture for the Linux
kernel, a piece of code that could go a long way toward
making the Penguin OS the obvious choice for security-minded
businesses and government agencies.

This month, members of the Maryland Columbia Area Linux
Users Group (CALUG) got a
peek at Security-Enhanced Linux (SELinux), as the
modified-by-NSA version of Linux is called. CALUG
coordinator Randy Schrickel, who does some consulting for
NSA himself, knew a bit about NSA's work. And because NSA's
headquarters at Fort Meade is near Columbia, Schrickel
called the agency to ask if someone would be willing to come
to the group's meeting to talk about it.

It was a treat. That night, in a second-floor room in an
otherwise empty office building, Loscocco, wearing most
unspy-like jeans and a faded red shirt, and the likewise
casually attired Steven Smalley, of NSA contractor NAI
Labs' Secure Executions Environments group, gave an
account of how their system worked.

SELinux, they explained, goes way beyond the firewalls and
file permissions that now guard *nix boxes. These kinds of
everyday security measures fall under the rubric of
discretionary access control (DAC).
The problem with DAC is that such protocols determine
security levels only by the identity of the users, not by
the actions they are trying to execute.
Under this general level of protection, a cracker can "own"
a system only by sussing out a sysadmin's password, or a
Trojan horse, but once inside the system, can do far more damage
as the OS has implicitly trusted the executable to do the
right thing.

A well-tuned MAC-enhanced system eliminates these
possibilities. "The mandatory access controls can confine
the actions of any process so that the potential damage that
can be done by exploiting a flaw in an application can be
strictly limited," Smalley writes on the SE
mailing list. SE protects raw data and the kernel
against any potential damage that can be caused through an
exploitation of a flaw in a process that requires
privileges. It also keeps ordinary user processes from
interfering with system processes or administrator
processes. MAC checks permissions of every process, file,
and socket being used against a matrix of allowable actions.
(For more detail, see Larry Loeb's analysis on IBM's
DeveloperWorks site, part
one and part
two. Or, if you really have some time to kill, read
NSA's own backgrounders on the Linux
implementation and the
architecture itself.

Smalley gave an example of how SE would toughen up a
Web server: While now it may be possible to drop some
malicious code through a CGI interface, with some sort of
MAC protection CGI commands could only access a small
subset of previously-defined actions, actions the sysadmin
had already set as permissible. A CGI command couldn't
execute at the level of the server itself, so a process
couldn't fork off and cause damage.

SELinux stems from NSA studies first done back in 1993 on
developing a secure MAC architecture -- eventually
the work led to an enhanced security architecture, called
Flask, the specifications of which were released in 1999.
NSA started applying Flask to Linux in the summer of
1999, and the first version of SELinux was released last
December. The basic architecture itself is platform
independent, Loscocco explains, and, in fact, the folks from
TrustedBSD have already contacted NSA about possible use to
leverage some of this work for their
own MAC controls, which aren't as flexible.

SELinux is not a separate software program, nor is it even a
separate Linux distro. Rather, the NSA team hopes to have it
built into the kernel itself. The security levels for users,
programs, and processes are set by the system administrator
through a kernel subsystem called a "security server," which
acts as an interface to check all policy decisions. It provides
control over execute permissions, file control permissions,
socket controls, and other process management services like
fork, getsid and sched. The policies
are customizable: They can be set at low-level fine-grain
levels or across higher system-wide levels. Even previously
omniscient root accounts aren't granted de-facto rights to
all operations.

Of course, with all SELinux's tune-ability, there is also the
distinct possibility that a less-than-purely thought-out
policy can wreak havoc. As Loscocco points out, "We give
the sysadmin enough rope to hang themselves."

And, as the talk went on, the CALUGers in the group were
quick to sniff out SE's other potential areas of grief for
Linux developers and sysadmins, as Linux users are wont to
do. For programmers, error messages would have to be a lot
more thoroughly thought out under SELinux. How to handle a
child process not returning data because the user didn't
have appropriate permission? Also, as of now, only the
ext2fs filesystem is recognized in SELInux. The policies on
files in other filesystems, like Fat32 or XFS, still have to
be set at a high level -- reducing flexibility. A third
perceived shortcoming is that while the Flask architecture
is itself platform independent, the Linux implementation is
Intel x86 platform-specific -- although Loscocco pointed out
that the code could easily be ported to other chips as well.

Then there is the old bugaboo of lag. As could be expected
with any system that checks each and every process, there's
bound to be some overhead, which may slow performance. When
asked, Loscocco admitted that users would feel it in some
cases. On most executions, he said. the overhead would be so small as
to be almost unnoticeable -- on the order of 1 to 2
percent -- thanks to a vector access cache. But on smaller
commands, it would be more noticeable. And one area where it
really would be felt would be in networking, where Smalley
admitted that the overhead could be as high as 10 percent.

While most of the meeting dealt with the technical
implications of SELinux, eventually the talk drifted towards
why the NSA was taking such an interest in Linux in the
first place.

And with good reason. It's not often that the secrecy-minded
NSA goes out on speaking engagements, much less offers help
to renegade software movements. Loeb wrote that NSA
introducing SELinux to the world is the "equivalent of the
Pope coming down off the balcony in Rome, working the crowd
with a few loaves of bread and some fishes, and then
inviting everyone to come over to his place to watch the
soccer game and have a few beers."

Of course, the conspiracy-minded among us could find motives
quite easily. And inevitably, someone in the back row asked
the question that, however embarrassing it may have been to
ask, nonetheless had to be asked: Is there some sort of back
door written into SELinux? Meaning, did the NSA plant secret
access points that it can use to gain entry into people's
computers?

It is a good question. After all, just last week it was reported that Germany is banning Microsoft software from its sensitive posts,
fearing that the NSA had already planted back doors in that
company's products, although German officials later denied the reports. The concern was also voiced last September,
when an ex-NSA analyst accused the agency of persuading some
commercial software companies to add booby-hatches to
their products. And a few
years ago, when the government was hammering out a standard
for creating electronic signatures, the NSA okayed a
proposed digital signature but didn't identify a serious
flaw that would allow a sophisticated party -- such as NSA -- to
install a trapdoor (NSA denies
this was the case). And let's not forget the supposed
"NSAkey"
that got Microsoft- and NSA-haters all in an indignant huff.

Loscocco's answer was simple -- and he was adamant that NSA's
goal is not to "pollute Linux." Back doors can't be done
with Open Source software like Linux, he said, at least not
without being discovered. After all, anyone can examine the
code to see what it does. Sooner or later, some inquisitive
programmer would find it.

But would they? After all, we're talking about code written
by America's greatest employer of mathematicians, and one of
the world's biggest users of computers. If anyone could plant secret
code in Open Source, it would be NSA. No slouches of the
deep calculations are they.

Loeb, who has examined the code in detail, would agree that
there is no sneaky business going on, although he wouldn't
go as far as to verify that there were no back doors. "I
have seen nothing in the code to indicate any computational
effort to swipe data, but to really answer that, the code
would have to be analyzed for dependencies that are not
obvious," Loeb emails. "The thing is, the released version
is sort of useless as is. It's a framework, much like a
Linux distribution. You have to set the permissions and
stuff. Doing that customization seems to cut off any way
that 'They' could count on to transmit data out of the
shell.

"But that's just my opinion. I can't truly prove it
mathematically."

Actually, SELinux has more to do with NSA's other mission,
the one fewer people know about. While its chief duty is
monitoring foreign communications for political and economic
items of interest, NSA has a second task of building
communications systems that can't be cracked, listened in
on, or otherwise compromised. As one CALUG member noted
after the meeting, "The wars between nations today are
economic ones." Especially since the Cold War, operatives
cut loose from foreign spy agencies are now engaged in all
manner of espionage for foreign companies and governments.
So it is in the United States' best interest, the argument goes,
that the government build crack-proof systems for U.S.
corporations.

And who better to do that than NSA itself, which knows a
thing or two about compromising systems? The agency's Web
site has a whole slew of
security-related technologies ready for some
enterprising companies to take out into the
marketplace -- from disk
sanitization to a wafer-coating
technique that prevents reverse engineering of chips.
And this is nothing new. Back in the '70s, when IBM was
working on what would soon become the government Data
Encryption Standard (DES), NSA brainboxes quietly stepped in
to assist Big Blue in refining its design. Turns out they'd
been secretly working on something similar for years.

But SELinux is the NSA's first outreach effort in Open Source.

SElinux seems to be the result of standard-issue technology
transfer -- the U.S. government's ongoing attempt to get
its own research into the marketplace to advance the
frontiers of technology and, not incidentally, bring down
the costs of the government systems those technologies are
employed in. Loscocco pointed out that night how the NSA,
like a lot of government agencies, is interested in using
Linux itself to cut costs. Many of the Department of
Defense's computers are required to have MAC implementations,
and SELinux addresses that need.

"They need a secure OS internally," emails Loeb. "They want
something they can put on cheap boxes that will still give
them the security they need and currently implement on lots
of disparate hardware. I think [SELinux] is really an
admission that the world has changed. They need MAC, but
only if it works can they use it on PCs"

In fact, Loscocco and Smalley told the CALUG group that it
really isn't NSA's chef goal to have SELinux itself
implemented in the kernel -- just that particular MAC security
server architecture. After all, Loscocco is pretty confident
that a MAC of some sort will be implemented in the future.
It would seem that development is heading in that
direction. In fact, there are about five other MAC designs
competing for Torvalds' attention. One is Linux Intrusion
Detection System (LIDS).
Kernel contributor Malcolm Beattie has an alpha MAC release
as well.

Both Loscocco and Smalley seemed earnest about what they
were doing, and in doing so, they are testing the Open
Source philosophy. After all, one of the tenets of Open
Source, at least according to the Open
Source Initiative is that "in order to get the maximum
benefit from the process, the maximum diversity of persons
and groups should be equally eligible to contribute to open
sources. Therefore we forbid any open-source license from
locking anybody out of the process." And would that include
America's premier spy agency?

Later this month, NSA will
present the Linux-gatekeepers with a tough choice. In the
long run, NSA's contributions could strengthen Linux
immeasurably, but will vocal Linux adherents really want a
kernel with "NSA inside"?