Could Linux Be Too Open for Our Own Good?

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.

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies