> From: Rick Smith <smith @
sctc .
com>
>
> 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.
Actually, Rick, your analysis below does show a lack of
understanding in the capabilities of most MLS systems. Your
analysis assumes that the MAC labels enforced by such systems
are strictly hierarchical, e.g.:
Top Secret
Secret
Confidential
Unclassified
But all B1 systems that I am aware of also provide categories
or compartmentalization of levels, creating a two-dimensional
array, e.g.
Classification Compartments
-------------- ----------------------------------
Top Secret Category A, Category B, ....
Secret Category A, Category B, ....
Confidential Category A, Category B, ....
Unclassified Category A, Category B, ....
The classification is typically an integer. The compartments are
usually a bit set. The actual setup can be considerably more complex
than this.
In order for information flow to occur, the reader (or recipient)
of the information must be have a label dominating the label of
the information, e.g., its
classification >= classification of data
compartment set a proper superset of the data's compartment set
This has considerable implications in your analysis.
>
> 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?"
Of course they can. See below.
>
> 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:
>
> 1) Typical Internet TCP/IP traffic does not contain labels.
> 2) The network interface in an MLS system is always assigned
> a label.
> 3) 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.
> 4) 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."
> 5) If two processes have the same label, there is no way to
> enforce mandatory MLS protection between them.
> 6) Every network server process is assigned a label.
> 7) A network server process can only send and receive
> packets if the packets' labels are identical to the label
> of the network server process.
Here your understanding of MLS networking breaks down. Read
the existing standards, such as RFC 1108 or the DoD's Common Security
Label spec. An interface is not controlled by a single label. Rather
it is given an accreditation range, or set of labels, over which it can
operate, e.g., Outside A, Outside A, Outside AB. You are correct that if
it receives an unlabeled packet, most systems will give it a single
default label regardless of port.
> 8) Any network server process that handles Internet traffic
> must be assigned the "Internet Label" (from 4, 7).
No, it must be assigned any within the accreditation set of the
interface.
> 9) All Internet server processes must be assigned the
> "Internet Label" (from 6, 8).
No, they can be assigned different labels.
> 10) You can't enforce MLS between Internet servers (from 5, 9).
Sure you can -- easily.
Server 1 (label = outside A) Server 2 (label = outside B)
| |
| |
Interface (default label = outside, accreditation set
= outside, outside A, outside B)
With the above configuration, both servers can access the external
interface. They can both read/write. They are completely separated
by MAC. It is true that they must bind to a port, but the port
space is not protected by any label, for it does not by itself contain
any information. Proper separation is provided by the underlying
protocol stack, which only permits a single process to bind to any given
port.
I'll certainly admit that it isn't the prettiest solution, but it sure
works well. This has been the standard MLS approach for over 7 years,
and it is well documented.
We'll skip the remaining analysis, as it is based on incorrect
assumptions.
...
>
> 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
As shown above, this is not necessary. Most, if not all, MLS
vendors already have these capabilities.
> 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.
Now I'm not an expert on Type Enforcement, but we do have a couple
of ex-SCC developers here. We've discussed the pros/cons of
TE vs. MLS at length for quite some time and have come to the conclusion
that ANYTHING that can be done with TE can also be done with MLS and
vice versa. Of course the architectures are different, and some
problems fit more naturally with one or the other approach. But the
capabilites are virtually identical, particularly when applied to
firewalls and similar separation problems.
Charles Watt
SecureWare, Inc.
|
|
