The Official Unofficial Zorp project
Overview| Examples| Bugs| FAQ | White papers | Download | Help wanted | SourceForge Project page | Filltable utility Project News: Zorp unofficial
  • zorp 2.0.9-6 has been released
  • iptables-utils zorp-unoff version has been released
  • New whitepaper, even more FAQs
  • Zorp whitepapers released, new FAQs
  • New tproxy versions
  • New Zorp version: get the DN
  • The best bughunter
  • Bughunting contest extended
  • Valentine day bughunting contest!
  • Site updates: FAQ, design
  • Project File Releases: Zorp unofficial
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:49:58 GMT)
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:40:56 GMT)
  • iptables-utils 1.21-1 released (Mon, 01 Nov 2004 21:19:42 GMT)
  • zorp 2.0.9-1 released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorplibll released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorp zorp_2.0.8-1 released (Thu, 11 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-2 released (Wed, 03 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-1 released (Tue, 11 Nov 2003 00:00:00 GMT)
  • zorplibll zorplibll_2.0.26.23-1 released (Mon, 10 Nov 2003 00:00:00 GMT)
  • download
    FRirewalls and information flow control policy
    This document is not part of the "Zorp Anatomy" series.
    It does not talk about the inner workings of Zorp,
    but talks about more general questions related to firewalling.
    Thanks to Attila Kósa for asking the questions.
    One function of firewalls is controlling the information flow.
    In other words the firewall should enforce the organisational information
    flow control policy. This is a mandatory access control policy,
    and because of its mandatoryness, it should be enforced in all
    mechanisms of the organisation pertaining to information, not
    just IT.
    All of the current network perimeter security solutions (nearly all,
    because we have the DragonFly) solves this problem by giving more
    or less (less) effective tools to the hand of firewall administrator
    to enforce a discretionary access control policy. From this
    discretionary access control we will create mandatory access control
    by hoping that the firewall admin
    1. respects the information flow modell
    2. have the necessary information on the security properties of
     the objects and subjects
    3. the tools used are adeqate to enforce the information flow control
    4. did not do a mistake, or if did, this mistake can be detected and
    Let's see the above points one by one
    1. It is very rare that we even have a formulation of the information
    flow control bolicy beyond such vague definitions like "the sensitive
    data of the organisation should be protected" or "resources of the
    organisation should be protected from unauthorized access".
    From these expressions one can draw an information flow control policy
    with more or less difficulties, but it is very rare.
    Because of that the firewall administrators used to configure the
    rules by intuition, and have hard times explaining the reasons
    for them to those who are not interested in security.
    2. As soon as a system exceeds the size which can be overviewed by
    one individual (I can show an example where it is succeded in one
    single PC:), there will be some delimination of functions ideally.
    It is often comes with the fact that the enforcement of security
    policy and the knowledge of security attributes will not be focused
    in the same brain. This problem is more acute than it seems to be:
    the security attributes are defined by the user and developer/integrator
    in a way that they don't even know that they do it. The firewall admin
    can try to dig it up from them, but it is very hard. This can be
    made much easier by making definition of security attributes an
    explicit activity without which the system does not function.
    3. It os not easy to build a timber house with a penknife. The
    packet filtering routers and firewalls can solve some very basic
    problems. To enforce the information flow policy, you need more, like
    covert channel reduction. Given the current state of network protocolls,
    the firewall have very few chance to do it, even if it can handle every
    single protocol element. Even Zorp is not close to this goal,
    and other firewalls have no chance in it. 
    Let's consider its configuration overhead. With a configuration
    based on discretionary access control you will have configuration
    items on the magnitude of (N*K)*(N*K-1)/2*(P*Q), where
    N=number of hosts, K=number of security levels by hosts,
    P=number of protocols, Q=number of protocol elements by protocol.
    With 10 hosts and 5 protocols you have 7500 things to configure
    theoretically, and it is even something in order of 3000 in
    practice. This can be lowered by clever configuration tricks,
    until you arrive to the concept of describing not the connections
    but the definition of objects and subjects. Because the rest
    is a function of it.
    4. Everyone make mistakes (even me very rarely:). It os more so if
    you have to configure 3000 things in one afternoon. In this cases it
    is helpful if you have only few possibilities to err. For example the
    system is failsafe. It seems that a connection does not adhere to the
    information flow control policy? The firewall logic should deny it.
    The firewall admin have a relatively good feedback this way: the user
    will cry if a connection is really needed. The number of security
    attributes is fewer than the number of firewall rules with discretionary
    access control. That means that overviewing the attributes is not too complex,
    and simple rules based on zone hierarchy (like the ones in the current
    Zorp policy) make pinning the problems more easy, or lessen the
    number of attributes to overview drastically.
    And another advantage: this way delimination of functions can say
    that defining security attributes is not the role of the firewall
    administrator. One less problem:)