Multilevel Security and Internet Servers

I wrote the following message as part of a discussion on the old Firewalls mailing list in 1996. The message was part of a discussion on the use of MLS technology to protect Internet servers from attack. The basic concepts still apply in some ways, though the threats have evolved in many other ways.

The message opens with a summary of my background in MLS (through 1996, anyway) motivated by some questions raised in the discussion. Then it explains why, based on classical MLS reasoning, you can't use MLS to enforce separation between different Internet servers that share a common network interface. The article ends by explaining how an MLS-based Internet server can enforce the separation once we change our assumptions about how MLS works. An unspoken assumption of this discussion is that a "firewall" might be a large scale device that hosts a variety of "secure" services, like e-mail and DNS. Only a handful of firewalls (notably Secure Computing's Sidewinder) do anything like this today.

Someday I'd like to reconstruct the entire discussion from my own archives and from copies on the Internet, since it was a particularly satisfying one. It led to a paper I presented at ACSAC later that year. Click here to see the paper (PDF).

FROM: Rick Smith

DATE: 01/31/1996 15:09:50

SUBJECT: Re: Mandatory protection (was: product selection)

I think we`ve covered most of the issues so far in the Type Enforcement (TE) versus Multilevel Security (MLS) discussion pretty well, but there are two remaining issues that need clearing up.

I don`t think the unresolved topics arise from ignorance or a simple failure to communicate; we have a genuine and fully unintended culture clash.

The first is a matter of credibility. Since the relevance of anything else I say probably hinges on this, I`ll start here

"Does Rick Smith have a clue regarding MLS?"

There are several people at the National Computer Security Center and the MISSI Program Office that would be astonished by this question. Before moving to firewalls I was a key designer and the lead systems engineer on the SNS Mail Guard, one of the few MLS systems that comes close to being a turnkey device (I bring this up as evidence and not as a topic of Firewalls discussion - comment privately if you must). I`ve also done a variety of other MLS related analysis, design, and implementation tasks. So I do have some credentials.

But my background is entirely in high assurance MLS systems. Those are systems where MLS has only one meaning: obsessive protection of confidentiality in accordance with the Bell-LaPadula access control rules. Labels define barriers to information disclosure, and nothing in the platform architecture or services is permitted to compromise confidentiality. My statements on what MLS systems can and can`t do are based on the implications of highly assured confidentiality, not on some "strawman" MLS notion nor on "misconfigured" MLS systems.

That`s where the culture clash comes in. My colleagues in this discussion are using B1 MLS systems. These are systems where confidentiality protection is not pursued to such an extreme. This is *not* intended as a put-down, especially in the firewalls environment. Firewalls don`t need obsessively strong confidentiality. They need integrity protection. That`s why we put TE in Sidewinder and left out MLS -- we see MLS as a confidentiality mechanism and that`s not what we needed. But if you`re using MLS for mandatory protection and don`t have an obsessively strong confidentiality objective, then the picture changes a bit.

Here`s how this relates to the last open technical issue:

"Can MLS systems protect Internet servers from one another?"

I`ve always recognized that MLS systems can impose mandatory protection bariers between processes by using levels, categories, and compartments, but I still concluded "No." This is based on my view of high assurance MLS obsessed with confidentiality. The argument goes as follows:

Typical Internet TCP/IP traffic does not contain labels.
The network interface in an MLS system is always assigned a label.
If a network interface receives a packet that does not already contain a label, then the packet must be assigned the network interface`s label.
All packets sent or received as typical Internet TCP/IP traffic carry the same label (from 1, 2, 3). Call this label the "Internet Label."
If two processes have the same label, there is no way to enforce mandatory MLS protection between them.
Every network server process is assigned a label.
A network server process can only send and receive packets if the packets` labels are identical to the label of the network server process.
Any network server process that handles Internet traffic must be assigned the "Internet Label" (from 4, 7).
All Internet server processes must be assigned the "Internet Label" (from 6, 8).
You can`t enforce MLS between Internet servers (from 5, 9).

I suspect our misunderstandings are tied to statement 3) above. On Sidewinder we can associate TCP/IP port numbers with separately labeled domains in the TE system. The only way you can get a similar result in an MLS system is to associate TCP/IP port numbers with MLS confidentiality labels. For example, the B1 system might define a category or compartment label for "Mail" and restrict Port 25 traffic to processes with the Mail label. If so, this changes how statement 3) is phrased, and completely changes the conclusion.

The problem is, you can`t assign MLS labels that way if you`re obsessed with confidentiality. I can think of three reasons immediately as to why not:

1) Port numbers aren`t confidentiality labels and aren`t intended to be. There`s no reason to believe that any other system you`re communicating with is going to keep traffic separte according to port numbers. This means you can`t depend on confidentiality, the prime objective. This leads to the next reason:

2) Treating a port number like a label establishes an uncontrolled data channel between processes with different labels, independent of the label enforcement rules. This is because there`s nothing in the TCP/IP operating concept to prevent one such process from opening a connection directly or indrectly to a process on the same system associated with a different port number, bypassing the MLS barriers between differently labeled processes.

3) You can almost certainly construct a nifty timing channel between two processes that have different labels/ports and share the same TCP/IP stack. So even if the rest of the network behaves, there are ways to circumvent the labels.

But the bottom line answer to the question, in the context of *firewalls* and the irrelevance to them of a high assurance obsession with confidentiality, appears to be "Yes, If."

IF the vendor puts in the trusted code to associate different port numbers with different MLS process labels, THEN their firewall *can* enforce mandatory MLS protection between Internet servers. It`s not clear that a firewall is "misconfigured" if this degree of protection is omitted, but a thorough implementation really should include it. So, if you`re buying an MLS based firewall, look for this feature.

Peace?

Rick.

smith at secure computing corporation