Re: [firewall-wizards] Trusted OS...

[Jackie_Soares () gap com]

> Having a trusted OS have little to do with the firewall functionality.
> Firewalls are substitues of real security on the defended nets, and they
> tend to have very few users, usually only with one level of trust (fully
> trusted).

I think you've hit it on the nose.  In TCSEC security models (higher than
C2), the underlying TCB helps manage single-level or multi-level secured
subjects. In order for a network to be "trusted", all the components are
trusted; and evaluated as trusted on the same security level.  The devices
attached to this single level secured network are controlled with MAC
(Mandantory Access Control).  Multi-level secured (MLS) software must be
written (with trust and modelling (i.e. INAJO, etc.)) so that it connects
two or more single-level secured subjects together with trust.  In this case,
we are talking about a network "guard" not a firewall.

In the TCSEC security models, some people confused the term "multi-level
secure downgrade or upgrade guards" with "firewalls."  A firewall is a filter.
It blocks traffic; it shapes traffic; it translates traffic.  But a firewall
does not have the capacity nor the ability to downgrade secured information
from one level (Top Secret) do another level (Confidential) or upgrading of
unsecured messages through a single-level highly secured network.  A
MLS guard has to have the ability to isolate datagrams or build messages from
datagrams, audit, review, make changes to the message, repackage the message,
set the appropriate DAC (Discretionary Access Control), and move the content
up or down to the appropriate single-level network through a MLS controlled
by the MAC.

One example is a "manual-review" downgrade guard. In a "manual-review"
guard, it takes a multi-level subject (usually a human being) to review
the material and block out inappropriate portions (ala black highlighter)
and allow some of information to pass through. (For instance, material
obtained from the Freedom of Information Act blocks out surnames,
addresses, and telephone numbers).

In a "software-review" guard, the data received has to be formatted in a
particular manner, the source is authenticated and sealed.  If the data
comes from a single level network, it is easier to authenticate, audit,
and review. [And evaluate, if you are taking your product through TCSEC
evaluation.]  If the data comes from an unsecured network (i.e. Internet),
then additional methods must be taken to protect the network interface,
the code and computer from subversion; reduce the exploitation of covert
channels, and use orthogonal technologies such as VPN, S-KEY, cryptographic
checksums, network puzzles, firewalls [note: here's where the firewalls
come in], etc. to increase chances that the guard receives the appropriate
datagrams.  Note: on baseband protocols, data always arrives single-level,
then after it passes authentication, the auditing, the guard passes it
to a MLS that builds the message and reviews the content, modifies the
message (i.e. removes information with an electronic black highlighter)
and then determines a new appropriate DAC; builds packets; and sends the
packets to an assigned single level secured network.

If you are trying to use commercial-of-the-shelf COTS software to build
a guard; I don't think there is product on the market that does this
at reasonable costs.  And nearly all COTS network products do not take
advantage of the MAC features of various vendors. The mandatory access
control features have to be configured separately.

To find a MLS COTS firewall product; I don't think it exists. Because
firewalls are inherently single-level filters.

> If you consider the NTCB modell of TCSEC, the picture gets to be a little
> more fine. The main point is that you cannot guarantee the integrity of
> the application (firewall proxies) if you don't have a TCB under it,
> and the firewall proxies are integral part of the NTCB (anywhere between
> 'M' and 'MIA' component). The little problem with this that no firewall
> (which I know about) have been specifically designed az an M component
> of an NTCB. The other problem is that no network protocol I know of
> is designed for transmitting the labels as well (though some of them
> like smtp and http is able to do that.

Installing an untrusted application (firewall) on a TCB does not make the
application run with more trust.  You still have a untrusted application
running on a TCB.  If it is a UNIX-based TCB, you can assign with MAC to
run your untrusted software single-level to single level network interfaces.
You should also be able to run another copy of the the untrusted
application in another "address space" but are required to attach to
different network interfaces because the MAC setup reserved the first
interfaces for the first instance of the application. A TCB should
prevent passing data from one address-space to the other without a
trusted MLS subject--this includes sharing the same transmit and
receive buffers on the network interface card.  However, one advantage of
using a TCB, you will have the ability to manage interfaces where you might
not on a untrusted OS.

Mr Arpad is absolutely correct.  Integrity of the network applications
depends on the software. Starting with a good TCB is only a small portion
of success.  To take advantage of a trusted multi-level secured OS, the
foundation of layering of trusted code over an evaluated TCB using
the same programming methodology and evaluation that built the TCB
process is a way to go.  But the process is a very difficult path to
follow.  Lots of Mil Specs, tedious documentation, and rigourous QA
and review.

The successors in this field are found at
http://www.radium.ncsc.mil/tpep/epl/

Also, refer to
http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-94-008.html

Jackie Soares
Network Systems Consultant
Gap, Inc.