Could Linux Be Too Open for Our Own Good?

by Larry Loeb

August 27, 2001 —

There are times when things encountered can be unexpected and
surprising, and they can change the way you think about things ever
after. Kirkegaard -- that old funster -- said that once the Abyss has
been seen, it can't be unseen. It's like the first time that you go to
one particular Web site. It seems impossible, but there it is: naked
ladies reading the news. The anchor lady doing a strip while talking
about Iraq. The weather girl kicking up her heels about a forecast.
Literally. And it's free, everyday. Originating from Toronto every
Monday through Friday and operating for over a year, it's set up for
all popular Web video players and connection speeds. Makes you wonder
if Peter Jennings is wearing trousers under that desk. And you want
Lynn Russell of CNN Headline News to take her glasses off -- slowly.

That's sort of what I was feeling when I first saw that the National
Security Agency was releasing a secured version of Linux 2.2 into
the "open source" community, along with the background on the testing
models it used for verification. It was just too weird to be happening.
The people behind the triple fence in Fort Meade, Md. giving out
something? Sources to their code? Verification strategies with
annotations? The same folk who used to be able to make any cryptography
that they didn't like disappear forever? The sheer immense significance
of what this release of code implied was stunning, like a hard punch to
the gut.

Now, there had been previous calls for the NSA to change its
organization, how it did its business. The "New Enterprise Team" report
of October 1999 was all about changing the way the NSA should fulfill
its mission. The teams' recommendations included:

1. Update, complete and implement the vision and mission statements
and disseminate the information broadly.
2. Change the organization, the underlying funding model, and
management practices to enable accountability and empowerment of
individuals closest to mission execution -- the "mission
managers."
3. Charge responsible managers to invest in order to avoid
technical and mission obsolescence.
4. Develop and emphasize business planning, program management, and
systems engineering skills needed to meet changing environment.
5. Foster a new culture that emphasizes openness, flexibility, and
personal performance.
6. Acquire, develop and keep skills necessary for future success.
7. Influence, and be influenced by, the Agency's stakeholders.
8. Correct the promotion system and emphasize that promotion is
based on performance and job responsibility.

It's point number five, with its call for a new culture of openness
that stuck out to me when I read it. What was being recommended here
was the antithesis of everything the NSA was and had been.

Yet, this point seems to have been internalized by the organization.
They have put up a new Web site that tries to pump up the jobs that it
has to offer internally by comparing a career at the NSA to a roller-
coaster ride. (Hence, the hackerati tag of "The NSA roller-coaster
site.") They are, however painful it is to them, looking to the outside
for help in doing that voodoo that they have done so well. They would
benefit from a secure OS as much as anyone else, and finally seem to
realize they can't do it alone. The mountain has indeed come to
Mohammed.

Let's look at some characteristics of the actual system that they
released into the world. SELinux uses mandatory access controls to
enforce the separation of information based on confidentiality and
integrity requirements to provide system security. SEL uses a flexible
mandatory access control architecture based on Type Enforcement, a
mechanism first developed for the LOCK system. The architecture was
transferred to the University of Utah's Fluke research operating
system. At this point, the architecture was changed to provide better
support for dynamic security policies, and the architecture was renamed
Flask. This is what is used in SEL.

In the Flask architecture, the security policy logic is encapsulated
within a separate component of the operating system with a general
interface for obtaining security policy decisions. This separate
component is referred to as the security server, which is a kernel
subsystem in SEL. Other subsystems are called object managers. Flask
specifies the interfaces provided by the security servers to object
managers. This way, the object managers can remain independent of the
specific security policy that is used. SEL's security server has a
security policy that combines Type Enforcement, role-based access
controls (RBAC) and multi-level security. One can specify which
combination of the above methods is desired with a policy language
configuration file. This is compiled into a binary representation that
is read by the security server at boot time.

SEL revalidates each security permission on use, including file
read/write and those used for communicating on an established
connection. This means that policy changes can be implemented at
runtime as well, based on information stored somewhere else (such as a
remote file) that is used to reconfigure the security policies. But the
security label of a process can only change upon program execution.
This implies that the inheritance of state as well as process
initialization can be controlled.

The mapping between each program object and the security attributes for
that object is done in SEL using a file in a fixed subdirectory of the
root directory of each file system. The mapping is loaded into memory
every time the file system is mounted, and updated every time a new
security label is encountered.

This is an entirely different way to handle access permissions,
compared to the user/privilege model most UNIX systems currently use.
SEL could implement that model along with a granularity that could
modify user privileges based on the specifics of what is being executed
and what files are being used. Pretty powerful stuff.

SEL is based on the 2.2 Linux kernel, which has some known security
issues. 2.4 was just released, which can scale up to S/390 levels under
VM. Expect SEL to be ported to the newer kernel at some point in the
future.

Imagine. The NSA has let a genie out of the bottle and there's no way
to stuff it back in that bottle now. It should be an interesting ride.

ITworld