5. Security functional requirements

The security functional requirements are labeled with a reference. Each reference have the form SYSTEM:COMPONENT, where component is the name of the part2 security functional requirement component, and system is either TOE, ENV, or BUS.

The requirements which have been labeled as TOE, are requirements against the TOE. The requirements which have been labeled ENV, are requirements against the IT environment of the TOE. The requirements which have been labeled as BUS, are requirements against the business function of the TOE, which means that the IT environment can relay on it as a requirement stated against the IT environment of the IT environment which is the TOE itself.

5.1 Security Audit (FAU)

Audit Data Generation (TOE:FAU_GEN.1)

The TSF shall be able to generate an audit record of the auditable events listed below. This includes all auditable events for the basic level of audit.

refinement: The TOE shall generate audit trails no longer than 1024 characters. Should the length of the audit trail would exceed this limit, it should be truncated on the end. The audit trail should only contain known nonproblematic characters.

The TSF shall record within each audit record at least the following information:

• Type of event
• Caller subject identity
• The additional information specified in the list below.

1. The startup and shutdown of the TOE, hence its audit functions, with the parameters by which it is called.
2. The output of the TOE, with all the packet filter rules emitted.
3. Errors parsing the input, with the line number in the input file
4. Other error conditions, except the ones related to command line argument parsing, with full python traceback.

Application notes:

• The original "subject identity" of LSPP is changed to "caller subject identity", which means the unix uid and euid of the subject calling the TOE, as the subject identity of the junior system administrator who have modified the input data cannot acquired. Possible ways of further development include making the TOE a daemon listening on a unix domain socket for triggers for upgrade. In this case the subject identity could be acquired through a SCM_CREDENTIALS ancillary message, or through a recvmsg_secure call if we assume SELinux.
• The original "sensitivity labels of subjects, objects, or information involved" of LSPP is dropped, but the table of auditable event contains all the invocation parameters of the TOE. This makes possible to implicitly assign a label either to the (part of) basedir, table or chain involved. The input file format also contains a "label" field which is unused yet. Possible ways of further development include using the label field to match packets having the label given, if it will be available to the packet filter someday.

User Identity Association (ENV:FAU_GEN.2)

The underlying operatin system shall be able to associate each auditable event with the identity of the user that caused the event.

Application note: the TOE supports this by auditing the unix uid and euid of the subject running the TOE.

User Identity Association support (SUP:FAU_GEN.2)

The TOE should include the unix uid and euid of the subject the TOE runs as in each audit records.

Applcatio note: To link either this or the subject which modified the input file is out of the TOE scope of control.

Audit Review (TOE:FAU_SAR.1)

The TOE shall generate the audit records in a manner suitable for the user to interpret the information.

Restricted Audit Review support (SUP:FAU_SAR.2)

The TOE shall generate audit trails only to the standard syslog interface and the standard error.

5.2 User Data Protection (FDP)

Export of unlabeled user data (TOE:FDP_ETC.1)

The TOE shall enforce the Filltable policy when exporting user data, controlled under the SFP(s), outside of the TSC.

The TSF shall export the user data without the user data's associated security attributes.

Application note: The utility does have an entry for labels in the input file format, but that is not used yet.

Complete information flow control (TOE:FDP_IFC.2)

The TSF shall enforce the Filltable policy on the packet filter configuration data and all operations that cause that information to flow to and from subjects covered by the SFP.

The TSF shall ensure that all operations that cause any information in the TSC to flow to and from any subject in the TSC are covered by an information flow control SFP.

Hierarchical security attributes (ENV:FDP_IFF.2)

The underlying operating system shall enforce the Filltable policy based on the following types of subject and information security attributes: filltable domain.

• the subject which the TOE runs as have to have write acces defined by the underlying operating system to its standard output and standard error, and read access defined by the underlying operating system to the input file.
• There is expected to be a least upper bound and a greatest lower bound of the information domains within the control of the underlying operating system.
• the filltable input domain is lower than the filltable output domain
• the filltable input domain is lower than the filltable audit domain
• there is no ordering relation defined in the TSC between the filltable output domain and the filltable audit domain.
• the information can only flow up

The TSF shall enforce the following relationships for any two valid information flow control security attributes:

1. There exists an ordering function that, given two valid security attributes, determines if the security attributes are equal, if one security attribute is greater than the other, or if the security attributes are incomparable; and
2. There exists a "least upper bound" in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is greater than or equal to the two valid security attributes; and
3. There exists a "greatest lower bound" in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is not greater than the two valid security attributes.

Application note: the ordering function is that the filltable input domain is lower than the filltable output and audit domains. The least upper bound is greater or equal than the filltable output domain, and the greatest lower bound is lower than equal than the filltable input domain.

Hierarchical security attributes (TOE:FDP_IFF.2)

The TSF shall enforce the Filltable policy based on the following types of subject and information security attributes: filltable domain.

The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules, based on the ordering relationships between security attributes hold:

• The filltable input domain is defined by the syntax rules of the input file.
• The filltable output domain is defined by the syntax rules of the output of the iptables-save utility.
• The filltable audit domain is defined by the syntax rules of the audit trail of the TOE.
• there is one operation: filltable-control, which causes the information to flow from the filltable input domain to the filltable output domain and the filltable audit domain, leaving the meaning of the information unchanged if semantic rules hold.

Application note: with ENV:FDP_IFF.2 we have the Bell&LaPadula modell here.

The TSF shall enforce the following additional flow control SFP rules:

• The TOE shall not consider more than 1024 octets of input per lines
• Only information which adheres to the syntax of the filltable input fomain can be accepted as input.
• Only information which adheres to the syntax of the filltable output domain can be generated as output.
• Only information which adheres to the syntax of the filltable audit domain can be generated as audit trail or error output.

Application note: we have the rules of the Clark-Wilson modell here

The TSF shall not provide additional SFP capabilities.

The TSF shall not explicitly authorize information flow based on any additional rules.

The TSF shall not explicitly deny information flow based on any additional rules.

No illicit information flows (TOE:FDP_IFF.5)

The TSF shall ensure that no illicit information flows exist to circumvent the filltable policy, to the extent to which the underlying operating system's information flow control policy covers the subjects and object interfacing with the TOE.

No illicit information flows (ENV:FDP_IFC.1)

The underlying operating system shall ensure that its information flow control policy covers all objects and subjects interacting with the TOE.

Import of user data without security attributes (TOE: FDP_ITC.1)

The TSF shall enforce the filltable policy when importing user data, controlled under the SFP, from outside of the TSC.

The TSF shall ignore any security attributes associated with the user data when imported from outside the TSC.

The TSF shall not enforce additional importation control rules when importing user data controlled under the SFP from outside the TSC.

5.3 Security Management (FMT)

Specification of Management Functions (TOE:SMT_SMF.1)

The TSF shall not be capable of performing any security management functions related to its own security functions.

Specification of Management Functions (BUS:SMT_SMF.1)

The TSF shall be capable of performing the following security management function related to the security functions of the underlying operating system:

• Control the subset of the packet filtering rules defined by an iptables chain given by the senior sytem administrator on the commandline.

Security roles (ENV:FMT_SMR.1)

The underlying operating system shall maintain the roles junior system administrator and senior system administrator

The underlying operating system shall be able to associate users with roles.

The underlying operating system shall ensure that the following conditions are satisfied:

• The senior system administrator is capable of writing the filltable output domain, reading the filltable input domain, and execute the filltable script with appropriate parameters.
• The junior system administrator is capable of writing the filltable input domain
• The junior system administrator is not capable of writing the filltable output domain
• The junior system administrator is not capable of interfering with the execution domain of the TOE.

5.4 Protection of the TSF (FPT)

Abstract machine testing (TOE:FPT_AMT.1)

The TSF shall run a suite of tests at the request of the senior system administrator to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF.

Application note: this is a TODO

Application note: the underlying abstract machine is the underlaying python interpreter and/or its re and os modules, which have the operating system under it.

Non-bypassability of the TSP (TOE:FPT_RVM.1)

The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed.

Complete reference monitor (ENV:FPT_SEP.3)

The unisolated portion of the TSF of the underlying operating system shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.

The TSF of the underlying operating system shall enforce separation between the security domains of subjects in the TSC.

The TSF of the underlying operating system shall maintain the TOE in a security domain for its own execution that protects them from interference and tampering by the remainder of the TSF of the operating system and by subjects untrusted with respect to the TSP.

Application note: the text "the part of the TSF that enforces the access control and/or information flow control SFPs" is changed to "the TOE", as it is the part of the TSF of the underlying operating system which enforces the information flow control SFP.

Reliable time stamps (ENV:FPT_STM.1)

The underlying operating system shall add reliable time stamps to the audit records generated by the TOE.

TSF testing (TOE:FPT_TST.1)

The TSF shall run a suite of self tests at the request of the senior system administrator to demonstrate the correct operation of the TSF.

Application note: the following text: "The TSF shall provide authorised users with the capability to verify the integrity of TSF data." is skipped, because there are no persistent TSF data.

The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.