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

[Paul McNabb <mcnabb () argus-systems com>]

Actually, the ability of a Trusted OS to protect a firewall is a little
greater than what Jackie has said.  It is true that in most old-style
(1st-2nd generation TOSes), there was little that the TOS could do to
help with securing network components, but with newer 3rd generation
TOSes, they can add significant security even if you are running only
commercial software on them.

For example, it is quite easy to limit on a *per-process* basis what
network resources a process can access; such as network interfaces,
subnets, IP address, ports, and protocols; including specific combinations
of these.  With a TOS, I can easily prevent a process connected to the
internet from ever sending a packet out another network interface (such
as an admin LAN).

With a TOS, I can allow a proxy process to communicate only with certain
port numbers over specific interfaces or to specific addresses or subnets.
I can allow access to firewall administration utilities only from certain
interfaces and certain IP address.

I can have traffic arriving on the same port numbers but on different
network interfaces or from different hosts to be routed to different
processes on the same machine.

And all of these restrictions will be in place even if an attacker
manages to "take over" a process via a stack overwrite bug or something
similar that allows that attack to have the process execute any sequence
of machine instructions and/or system calls.

All this being said, a TOS still won't make the commercial firewall
any more functional, and all the firewall's bugs will still be there.
(Although the TOS networking components will allow some packet filtering
by itself and so may help a little.)  The main strengths of the TOS in
relation to a firewall are related to protecting the administration and
in isolating and preventing damage from compromised components, such as
proxies.

These third generation TOSes are significantly more functional and more
secure than those that appeared 5-15 years ago in the government markets.
Plus they run all commercial software designed for the underlying OS,
they are installable on top of a running OS (no more installing a new
OS, just a piece of commercial software like any other piece of software),
and they are generally available for the most recent releases of the
commercial OS rather than being several releases out of date.

paul

---------------------------------------------------------
Paul A. McNabb, CISSP           Argus Systems Group, Inc.
Senior Vice President and CTO   1809 Woodfield Drive
mcnabb () argus-systems com        Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433                "Securing the Future"
---------------------------------------------------------

>  From owner-firewall-wizards () lists nfr net  Wed Mar  8 22:05:33 2000
>  From: Jackie_Soares () gap com
>  To: Magosanyi Arpad <mag () bunuel tii matav hu>
>  cc: Firewall Wizards <Firewall-Wizards () nfr net>,
>          John_Williams-CRMProductDev () peoplesoft com
>  Date: Tue, 7 Mar 2000 02:00:50 -0800
>  Subject: Re: [firewall-wizards] Trusted OS...
>  
>  
>  >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.
>  
>