The Official Unofficial Zorp project
 
Overview| Examples| Bugs| FAQ | White papers | Download | Help wanted | SourceForge Project page | Filltable utility  
 
 
SourceForge.net: SF.net 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
  • SourceForge.net: 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 2.0.26.24-1 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)
  • Next Previous Contents

    9. TOE Summary specification

    9.1 IT security functions

    Input validation

    • VAL-1: input syntax The input of the TOE is a text file containing lines separated by newline characters. There are two types of lines.
      • A comment is a line which starts with a hashmark (#) character. Comments are not processed.
      • All non-comment lines consist of fields separated by the pipe (|) character. The syntax and accepted values of each field is stricter or equal than that of the corresponding iptables parameter.
      The length of a line cannot exceed the length of 1023 characters.
    • VAL-2: syntax check The input file is either fits to the syntax rules, or will be rejected as a whole. No output is generated if there are any nonconformances to the syntax.
    • VAL-3: value check The values of the fields of non-comment lines are checked. If any value fails to be within bounds, the input file will be rejected as a whole, and no output will be generated. Inter-dependencies of acceptable values are not checked.

    Output

    • OUT-1: Output format The output of the TOE is a syntactically correct iptables dump, similar to the one created by iptables-save(8).
    • OUT-2: Output audit The TOE audits its whole output.

    Information flow

    • MAC-1: Allowed information flows
      • The TOE reads from its input file
      • The TOE writes its output to its standard output
      • The TOE writes audit trails to its standard error
      • The TOE writes audit trails to the system log throught the appropriate system-dependent mechanism (in linux it is currently a unix domain socket).
      • The pyton interpreter and the operating system underlying the TOE uses several mechanisms to create the runtime environment of the TOE (memory mapped shared libraries, program text, root and working directory, /proc files). The TOE does not modify these.
      • The TOE does not use other files, pipes, sockets, IPC mechanisms, whatsoever for any reason.
    • MAC-2: transformation semantics The information of the input file is converted from the format of the filltable input domain to the format of the filltable output domain by conserving the meaning of the information iff the input file is within the syntactic space of the filltable input domain.

    Security management

    • MGM-1: No security management functions The TOE does not provide any interfaces to manage its security functions.

    Protection of the TSF

    • PRO-1: test suite The TOE should have a test suite testing
      • the assumptions provided by the underlying operating system and the pyton interpreter with its modules.
      • the correct operation of the TSF
      The test suite should be suitable to be used only to test the underlying abstract machine or only the TOE, or both.

      The test suite should be suitable to do all tests required by the ATE_COV.2, ATE_DPT.1, ATE_FUN.1 and ATE_IND.2 requirements.

    Audit

    • AUD-1: Subject identity association. The TOE uses in its audit trails the identifiers established and maintained by the underlying operating system: the unix uid, euid and pid. The TOE handles these values as opaque ones: leaves the interpretation of them to the underlying operating system and the analyzer of the audit trail.
    • AUD-2: Event type. All audit trails should descriptively record the type of event occurred.
    • AUD-3: Operational errors. The TOE audits the following error conditions:
      • errors in the underlying operating system and python modules which raise an exception, with the corresponding python backtrace.
      • nonconformance to the input rules, with the corresponding line number.
      when it
      • parses its command line arguments
      • parses and checks the input
      • generates the output
    • AUD-4: startup and shutdown The TOE audits its startup and shutdown, hence the startup and shutdown of its audit subsystem. The startup message contains all the runtime parameters.
    • AUD-5: protection of the underlying audit subsystem The TOE logs at most 1024 characters in the FIXME message (?) field of the audit trail. If the field would exceed this limit, it is truncated in the end. All characters of the audit trail outside a set of "known good" characters are converted to a dot(.) character.
    • AUD-6: Interpretable audit The administrative guidance (as defined by AGD_ADM) should list all the possible events, denoting their outcome (success or failure), and the informations necessary to interpret them. All informations in the audit trail which is not corresponding to out-of-syntax input should be made of "known good" characters.
    • AUD-7: Restricted audit output The TOE shall generate audit trails only to the standard syslog interface and the standard error.

    9.2 Rationale for the IT security functions

    All security functional requirements of the TOE are covered.

    • TOE:FAU_GEN.1 The refinement is covered by AUD-3. The type of the event is covered by AUD-2. The caller subject identity is covered by AUD-1. Event 1 is covered by AUD-5. Event 2 is covered by OUT-2. Event 3 is covered by AUD-3. Event 4 is covered by AUD-4. The requirement of outcome is covered by AUD-6.
    • SUP:FAU_GEN.2 is covered by AUD-1.
    • TOE:FAU_SAR.1 is covered by AUD-6.
    • SUP:FAU_SAR.2 is covered by AUD-7.
    • TOE:FDP_ETC.2 is covered by OUT-1, MAC-1, MAC-2, AUD-5 ad AUD-6, as seen in the rationale for TOE:FDP_IFF.2.
    • TOE:FDP_IFC.2 is covered by OUT-1, MAC-1, MAC-2, AUD-5 ad AUD-6, as seen in the rationale for TOE:FDP_IFF.2.
    • TOE:FDP_IFF.2 The syntax rules of input file are defined by VAL-1. The syntax rules of the output are defined by OUT-1. The the syntax rules of the audit trail are defined by AUD-5 and AUD-6. The properties of filltable-control are enforced by MAC-1 and MAC-2. The additional FSP rules are also enforced by VAL-1, VAL-1, OUT-1, and AUD-5 with AUD-6 respectively.
    • TOE:FDP_IFF.5 is enforced by MAC-1.
    • TOE:FDP_ITC.2 is covered by VAL-1, MAC-1 and MAC-2 as seen in the rationale for TOE:FDP_IFF.2.
    • TOE:SMT_SMF.1 is covered by MGM-1.
    • BUS:SMT_SMF.1 is covered by VAL-1, OUT-1, MAC-1, and MAC-2.
    • TOE:FPT_AMT.1 is covered by PRO-1.
    • TOE:FPT_RVM.1 is covered by VAL-2 and VAL-3.
    • TOE:FPT_TST.1 is covered by PRO-1.

    All IT security functions are necessary

    • VAL-1: Covered by TOE:FDP_IFF.2 , TOE:FDP_IFF.2 , TOE:FDP_ITC.2 and BUS:SMT_SMF.1.
    • VAL-2: Covered by TOE:FPT_RVM.1.
    • VAL-3: Covered by TOE:FPT_RVM.1.
    • OUT-1: Covered by TOE:FDP_ETC.2 , TOE:FDP_IFC.2 and BUS:SMT_SMF.1 .
    • OUT-2: Covered by TOE:FAU_GEN.1.
    • MAC-1: Covered by TOE:FDP_ETC.2, TOE:FDP_IFC.2, TOE:FDP_IFF.2 , TOE:FDP_IFF.5 , TOE:FDP_ITC.2 and BUS:SMT_SMF.1.
    • MAC-2: Covered by TOE:FDP_ETC.2, TOE:FDP_IFC.2, TOE:FDP_IFF.2 , TOE:FDP_ITC.2 and BUS:SMT_SMF.1.
    • MGM-1: Covered by TOE:SMT_SMF.1.
    • PRO-1: Covered by TOE:FPT_AMT.1 and TOE:FPT_TST.1.
    • AUD-1: Covered by TOE:FAU_GEN.1 and SUP:FAU_GEN.2.
    • AUD-2: Covered by TOE:FAU_GEN.1.
    • AUD-3: Covered by TOE:FAU_GEN.1.
    • AUD-4: Covered by TOE:FAU_GEN.1.
    • AUD-5: Covered by TOE:FAU_GEN.1 , TOE:FDP_ETC.2, TOE:FDP_IFC.2 and TOE:FDP_IFF.2.
    • AUD-6: Covered by TOE:FAU_GEN.1 , TOE:FAU_SAR.1 , TOE:FDP_ETC.2, TOE:FDP_IFC.2 and TOE:FDP_IFF.2
    • AUD-7: Covered by SUP:FAU_SAR.2

    9.3 Assurance measures

    You can find the list of evaluation evidences in the CM documentation, in section "configuration list". The documents labeled with "meas" describe documentation which describe assurance measures.

    9.4 Rationale for Assurance measures

    All assurance requirements are covered:

    • ACM_AUT.2 is covered by the CM documentation.
    • ACM_CAP.4 is covered by the CM documentation. The CM system used is GNU arch.
    • ACM_SCP.2 is covered by the CM documentation. All the documentation and the source code are covered by the CM system.
    • ADO_DEL.1 is covered by the Guidance documentation, section "Download"
    • ADO_IGS.1 is covered by the Guidance documentation, chapters "Build", "Installation", "Invoking filltable", "Environment" and "Tests".
    • ADV_FSP.1 is covered by the Security Target, section "TOE Summary specification".
    • ADV_HLD.2 is covered by the filltable script, the docstrings. Note: in normal case that would be the low-level design, but the TOE is very simple.
    • ADV_RCR.1 is covered by the filltable script, the leading docstring.
    • ADV_SPM.1 is covered by the Security Target, section "Security policy Model".
    • AGD_ADM.1 is covered by the Guidance documentation, sections "Invoking filltable", "Usage examples", "Environment" and "Input file". The Guidance documentation does not describe security parameters, as no security management of the TOE is possible.
    • AGD_USR.1 is covered by the Guidance documentation, sections "Usage examples", "Environment" and "Input file".
    • ALC_DVS.1 is covered by the Hacker's guide and the build configuration. Note that "confidentality ... of the TOE design and implementation in its development environment" is not applicable, as filltable is an Open Source software.
    • ATE_COV.2 is covered by the Test Documentation, section "Coverage".
    • ATE_DPT.1 is covered by the Test Documentation, section "Depth".
    • ATE_FUN.1 is covered by the Guidance documentation, section "Tests", and the Test suite, as comments and expected output.
    • ATE_IND.2 is covered by the Guidance Documentation, section "Download", "Build", "Installation", and "Tests".
    • AVA_MSU.1 is covered by the Guidance documentation, all sections. Rationale is provided in Vulnerability analysis, section "Guidance overview".
    • AVA_SOF.1 is covered by Vulnerability analysis, section "Evaluation of strength. Note that there are no SOF claims in the Security target.
    • AVA_VLA.1 is covered by Vulnerability analysis, all sections.


    Next Previous Contents