\documentclass[12pt,english]{scrbook}
\usepackage{babel}
\usepackage[latin1]{inputenc}
\usepackage{url}
\usepackage{tabularx}
\usepackage{longtable}
\usepackage{graphicx}
\usepackage{booktabs}
\usepackage{rotating}
\usepackage{varioref}
\usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue]{hyperref}
\usepackage{textcomp}
\usepackage[T1]{fontenc}
\usepackage{lmodern}

% 90 degrees rotated
\newcolumntype{R}{%
  >{\begin{turn}{90}%
          \hspace{0pt}}l%
  <{\end{turn}}%
}
\newcommand{\oh}{$\bullet$}

\hypersetup{
pdftitle={Zope 3.3 Common Criteria Evaluation},
pdfauthor={Christian Theune {\textless}ct@gocept.com{\textgreater};Steve
Alexander {\textless}steve@catbox.net{\textgreater};Jim Fulton
{\textless}jim@zope.com{\textgreater};Christian Zagrodnick
{\textless}cz@gocept.com{\textgreater}}
}

\subject{Security Target}
\title{Zope 3.3 Common Criteria Evaluation}
\author{Christian Theune \\
  Steve Alexander \\
  Jim Fulton \\
  Christian Zagrodnick}

\uppertitleback{
\begin{description}
    \item[Document Title:] Zope 3.3 Common Criteria Evaluation Security Target
    \item[DocumentID:] $ $Id: SecurityTarget.tex 67208 2006-04-21 12:30:55Z ctheune $ $
    \item[Version:] $ $Rev: 65684$ $
    \item[Status:] Final
    \item[Date:] $ $Date: 2006-04-21 08:30:55 -0400 (Fri, 21 Apr 2006) $ $
    \item[Author:] Christian Theune, ct@gocept.com
    \item[Author:] Steve Alexander, steve@catbox.net
    \item[Author:] Jim Fulton, jim@zope.com
    \item[Author:] Christian Zagrodnick, cz@gocept.com
  \end{description}
}
\date{\today}

\begin{document}
\maketitle
\tableofcontents
\newpage
\listoftables

\chapter{ST Introduction}

This chapter presents security target (ST) identification information and an
overview of the ST. The ST contains the information technology (IT) security
requirements of an identified Target of Evaluation (TOE) and specifies the
functional and assurance security measures offered by that TOE to meet stated
requirements. An ST principally defines:

\begin{itemize}
    \item A security problem expressed as a set of assumptions about the
    security aspects of the environment, a list of threats that the TOE is
    intended to counter, and any known rules with which the TOE must comply
    (Chapter ``TOE Security Environment'').

    \item A set of security objectives and a set of security requirements to
    address the security problem (Chapters ``Security Objectives'' and ``IT
    Security Requirements'').

    \item The IT security functions provided by the TOE that meet the set of
    requirements (Chapter ``TOE Summary Specification'').
\end{itemize}

The structure and content of this ST complies with the requirements specified
in the Common Criteria (CC), Part 1, Annex C, and Part 3, chapter 5.

\section{ST identification}

This section provides information needed to identify and control this ST and
its Target of Evaluation (TOE).

\begin{description}
  
  \item[ST Title:] Zope 3.3 Common Criteria Evaluation Security Target
 
  \item[ST Version:] \$Rev: 40485 \$ 

  \item[Revision Number:] 1

  \item[Date:] \$Date: 2005-12-02 17:44:46 +0100 (Fr, 02 Dez 2005) \$ 

  \item[Author:] Christian Theune, Steve Alexander, Jim Fulton, Christian Zagrodnick

  \item[TOE Identification:] Zope 3.3

  \item[TOE Version:] 3.3

  \item[TOE Platform:] Linux

  \item[CC Identification:] Common Criteria for Information Technology Security
  Evalation, Version 2.1, August 1999 (also known as ISO 15408) and all
  corresponding final interpretations.

  \item[Evaluation Assurance Level:] EAL 1 augmented with ADV\_SPM.1

  \item[PP Conformance:] none

  \item[Keywords:] Web Application Server, Web Application Framework
\end{description}

%___________________________________________________________________________

\section{ST overview}

The Target of Evaluation is Zope 3.3 in its non-default ``secure''
configuration (hereinafter called Zope for simplicity), a general purpose, open
source web application server and framework. It is used as a runtime
environment for custom applications that are build using the Zope 3 API and
component library.

Zope clients are standards conformant web browsers using HTTP or other network
client programs accessing the various network services provided by Zope. The
secure configuration for this evaluation considers only the use of the HTTP
server. Other network service components exist but are out of scope for this
evaluation.

Zope includes security functionality on three levels: 1. the definition of
permissions and privileges by developers and administrators, 2. the definition
of users and groups and granting privileges to them for various objects by
administrators and 3. the enforcement of those permissions during the runtime 
when an application is beeing used.

A summary of the TOE security functions can be found in Chapter ``TOE
description''. A detailed description of the security functions can be found in
chapter ``TOE Summary Specification''

%___________________________________________________________________________

\section{CC conformance}

This ST is CC Part 2 conformant and CC part 3 conformant at the level of
assurance EAL 1.


%___________________________________________________________________________



\chapter{TOE description}

This chapter provides context for the TOE evaluation by identifying the product
type and describing the evaluated configuration.

%___________________________________________________________________________


\section{Product type}

Zope's primary purpose is to provide an environment for running custom web
applications and their components. Additionally it provides a software library
and tools to support the development of new applications.

Zope is written as platform independent software using the Python programming
language. Therefore it is available for Windows, Linux, MacOS X and other
operating systems. The platform supported within this evaluation is Linux. 

% purpose one: running applications
The core functionality contains a web server with WebDAV support, an FTP server
and an XML/RPC server. It has components that provide functionality for
security management including administration of users, groups and privileges.
Other core components cover an object database, indexing mechanisms, workflow,
a web interface, SQL support, an XML-based and a non-XML based templating
mechanism, Python scripting, internationalization and localization support and
many more.

Zope is built with a flexible component architecture that allow the core system
to be extended by re-using components and adding new components based on
defined interfaces. This includes extending the server to support new network
services, authentication schemata, access to new relational databases and many
more while maintaining integrity within the core system.

% purpose two: building applications
Historically, Zope is used for building content management systems but is also
widely and successfully used to build web applications in the general sense.

Custom Zope applications are written as packages that can contain configuration
directives, templates, and Python code and classes. Those packages are intended
to work together seamlessly using the component architecture to plug them
together into more complex systems.

\section{Physical scope and boundary of the TOE}

The TOE  is physically described by the release files that are made available
on zope.org. For general supported platforms this is a set of source files and
utilities to compile and install Zope. 

The complete product consists of several independent software packages that
can be described as high-level components (not to be confused with the term
"component" in Zope's own sense):

\begin{enumerate}

\item Developer API, to define permissions and privileges, to map permissions
to privileges, and to declare what components of an application are protected
by which permission. 

\item Zope Object Database (ZODB), a transparent persistency layer that stores
Python objects into an object database. The ZODB manages a logical and physical
view on the data and allows for the use of a database server (Zope Enterprise
Objects, ZEO) to connect a cluster of multiple identical Zope servers to a
single database server. The ZODB supports typical enterprise-class functions
like transactions and clustering, yet it does not care for security on
the programming level. Typically the ZODB is used as the central storage for
application data, but can be accompanied by RDBMS or be replaced totally. The
use of additional or replacement data sources is not part of the evaluation.


\item Software library, allowing developers to build their own applications
based on Zope. Zope itself is formed by combining many components from this
library into a single program.  These components are also offered for re-use
outside of scope and for extension by developers.

\item Network component, for providing an HTTP server to access Zope and the
applications running inside Zope from a web browser.

\item Pluggable Authentication Utility (PAU), that, based on the credentials
presented through the network component, authenticates and identifies users for
a request to the Zope server. The PAU is part of the software library.

\item A protection component, that regulates access to application components
and assures that a user has the correct privileges granted for a component
before executing component accesses (getting attributes or setting attributes).
The access is regulated with a ``privilege-based access policy''.

\item A publication component, that connects requests from the network
component with the application objects. The publication component also connects
the request with the authentication utility and the protection component to
establish the security environment for a request.

\end{enumerate}

%___________________________________________________________________________


\section{Logical scope and boundary of the TOE}

The TOE logical boundary is defined by the following security-relevant
subsystems provided by the TOE:

\begin{description}

  \item[Protection] mediates each access to object attributes and methods and
    consults the authorization subsystem to decide whether to allow an access
    or not.

  \item[Authentication] uses information made available by a client request to
  authenticate a user for a request.

  \item[Authorization] manages privilege grants and implements a method to
  check whether a user was granted a privilege or not. It is consulted by the
  protection subsystem.

  \item[Auditing] receives and logs events through Zope 3's event system that
  are security relevant.

  \item[Transaction Management] provides ACID compatible transactions to secure
  the object database's state between multiple concurrent requests 

  \item[Publication / Server] provides a central entry point into the Zope 3
  process through multiple network services. The publication creates an
  internal representation of the network request and connects it with the
  protection subsystem, authentication subsystem and transaction management.

  \item[Configuration] provides a method to configure Zope software components.
  This configuration includes, among other options, the declaration of
  permissions, mapping the permissions to software components (interfaces,
  classes, attributes, etc.), and mapping privileges to permissions.

\end{description}

See section \vref{toe-sec-funcs} for more details regarding those sub-systems.

%___________________________________________________________________________

\chapter{TOE security environment}

%___________________________________________________________________________

\section{Assets}

The following primary assets have been identified:

\begin{longtable}[c]{lp{10cm}}
  \toprule 
  Asset Name & Description \\
  \midrule\endhead

  (Content) Objects & 
  Generic objects (instances of Python classes) that
  are stored and controlled by Zope and carry
  information that is to be protected. \\
  \bottomrule
  \caption{Primary Assets}
  \label{tab-assets}
\end{longtable}

The following secondary assets have been identified:

\begin{longtable}[c]{lp{10cm}}
  \toprule 
  Asset Name & Description \\
  \midrule\endhead
  Host System
   &
  The unit of computer hardware and software that forms the environment of Zope
  to run on. Typically a PC server with Linux installed.
   \\

  Operations
   & 
  Operations are the way of accessing and modifying
  data provided by (content) objects.
   \\

  Principals
   & 
  Principals are the systems representation of acting
  individuals. A principal acts in behalf of the user
  and represents a (content) object of its own.
   \\

  Permission
   & 
  A permission is a name guarding an operation.
   \\

  Privilege
   &
  A privilege is a collection of permissions, grouped under a given name.
  \\

  Privilege grants
   & 
  A privilege grant associates a principal (user or group) with a
  privilege that allows them to perform all operations that are 
  protected by permissions that belong to the granted privilege in the context
  of the grant.
   \\

  Audit data
   & 
  The data generated by the TOE audit subsystem.
   \\

  Transaction data
   & 
  All operations within Zope are held within ACID
  compatible transactions that are bound to each
  request from the outside and associated with a
  principal.
  \\
  \bottomrule
  \caption{Secondary Assets}
  \label{tab-sec-assets}

\end{longtable}

%___________________________________________________________________________
\section{Objects}

Objects are defined by both Zope and applications running on Zope. They are
used for storing data and providing functionality. 

Objects are stored in a hierarchy (i.e. a tree). Therefore for every object
you can determine its ancestors and descendants.  The object's place in the
hierarchy is called ``context''. Given an object, additional information can
be retrieved from its context.

%___________________________________________________________________________
\section{Subjects}

Zope has a concept of interactions, which model the interaction of one or more
users with the system.  An interaction keeps track of the users that are
participating in the interaction as ``participations''.  In the TOE,
interactions will have single users participating through Web requests
Special scenarios include not associating an
interaction with any participation at all (running on system level) or
associating an interaction with multiple participations, e.g. to include the
author of code stored in the system and the user running it.

In the terminology of common criteria, those interactions are the ``subjects''
causing operations within the TOE to be performed. The terms ``subject'' and
``interaction'' can be used interchangeably for the purpose of this
certification.

%___________________________________________________________________________

\section{Operations}

Operations are performed on objects. They are defined in an object's class. A
class is defined in the Python programming language and is identified by a
fully qualified name.


An operation is a name defined in a class. It may take a form of an attribute
or a method.

There are two possible kinds of access to an operation: reading, such as reading
an attribute or calling a method, and writing, such as setting or deleting an
attribute. Reading and writing can be guarded using different permissions.

Operations in the Zope terminology match the definition and use of
``operations'' in the terminology of common criteria.


%___________________________________________________________________________
\section{Permissions and privileges}

The access control policy includes a model of permissions and privileges.

Attributes and methods are protected by permissions, defined by a developer of
a component.

Privileges are defined by system administrators. Privileges are defined by a
bit number, a title and a description. There exist 3 default privileges:

\begin{itemize}
    \item bit=``0'', title=``Read'', description=``Read content''
    \item bit=``2'', title=``Write'', description=``Write content''
    \item bit=``4'', title=``Share'', description=``Share content (grant privileges)''
\end{itemize}

All even-numbered bits are reserved for allocation by the Zope system for
future use, all odd-numbered bits are free to be used by other parties.

A permission is mapped to a privilege by the system administrator, giving the
permission identifier and the bit number of the privilege. Multiple permissions
can be mapped to the same privilege.

Users can be granted privileges on individual objects that support sharing.
This is called ``sharing information''.

When a new object is added without sharing information, initial sharing
information will be applied by copying over the applicable sharing information
of the parent object and granting all applicable privileges to the creator(s).

Objects may support "`sharing'' by providing the ISharing interface. If an
object does not provide the ISharing interface the next object in the chain of
ancestors that provides ISharing will be considered for policy decisions.

%___________________________________________________________________________



\section{Assumptions (about the environment)}

The following assumptions need to be made about the TOE environment:

\begin{longtable}[c]{lp{10cm}}
  \toprule
  Assumption Name & Description \\
  \midrule

  A.OS & The machine and the operating system Zope is running on is physically
  secure. The system is administered such that the system is free from
  malicious software, such as viruses and Trojan horses. The operating system
  provides a true system clock. \\

  A.Admin & 
  The ``system-administrator'' of the above
  mentioned machine is competent and trustworthy.
   \\

  A.Network & 
  A network connection to the Zope services is
  present. All other network connections to the same host are
  secure in a way that the integrity of
  the host and operating system is preserved.
   \\

  A.Client & 
  The connection between client and Zope server is
  secure in a sense that the identification and
  authentication data is not monitored or interfered with. This can either be
  through the use of a private network or a secure channel using an SSL proxy
  with an encryption mechanism of at least 128-Bit RSA.
  \\

  A.Credential & 
  The user is keeping the credential to authenticate
  secret. \\

  \bottomrule
  \caption{Assumptions about the TOE environment.}
  \label{tab-A}
\end{longtable}

%___________________________________________________________________________



\section{Threats}

The following threat agents have been identified:

\begin{itemize} 
  
  \item Users having correct authentication credentials who might try to
  acquire more permission grants to get access to operations they should not.

  \item Users without correct authentication credentials for a certain
  principal trying to authenticate as this.

\end{itemize}

Additional threat agents with specific motivation, resources and skills have to
be identified for any specific application built using Zope 3. From the point
of a generic application server, attackers are either to be expected to  be
authenticated and trying to extend their level of access or not having been
authenticated at all and trying to break into the system.

The following threats against the assets have been identified:

\begin{longtable}[c]{lp{6cm}p{4cm}}
  \toprule
  Threat & Description & Asset\\
  \midrule\endhead

  T.IA
   & 
  An attacker might impersonate an authorized
  principal without providing the necessary
  credentials.
   & 
  Principal
   \\
  

  T.Perm
   & 
  A principal changes the permission grants
  without having the right to do so.
   & 
  Permission grants
   \\
  

  T.Operation
   & 
  A principal performs an operation on an object
  without having the correct permission.
   & 
  Operation, Object
   \\
  

  T.AuditFake
   & 
  An attacker might convince the audit data
  generation functions to log false information
  (date, time, type of event, outcome, user)
   & 
  Audit data
   \\
  

  T.Inconsistent
   & 
  An attacker might try to make the system use
  inconsistent information for deciding to allow
  or deny access to an operation to gain more
  access than intended.
   & 
  Secondary assets
   \\
  

  T.Transaction
   & 
  An attacker might try to perform commit or
  abort operations on foreign transactions to
  perform operations on the behalf of other
  users.
   & 
  All assets in ZODB
   \\
  
  T.Timestamps
   & 
  An attacker might try to hide his actions
  by making the system create false timestamps
  which would result in wrong association to a
  user on dynamic IP address ranges.
   & 
  Audit data
   \\
  

  T.Host
   & 
  An attacker might use Python functions that
  result in direct access to the host environment
  therefore compromising the host and Zope itself.
   & 
  Host, Object
  \\
  \bottomrule
\caption{Threats Against Assets}
\label{tab-threats}
\end{longtable}
  


%___________________________________________________________________________



\section{Organisational security policies}

OSPs are to be defined by the developer who creates applications using Zope and
the customer running those applications.  Zope as a general purpose application
server does neither require nor impose any OSPs.


%___________________________________________________________________________



\chapter{Security objectives}


%___________________________________________________________________________



\section{Security objectives for the TOE}

The following security objectives have been defined for the TOE:

\begin{longtable}[c]{lp{10cm}}
  \toprule
  Objective Name & Description \\
  \midrule\endhead
  
  O.IA
   & 
  All principals must be accurately identified and
  authenticated with the exception of the ``unauthenticated''
  principal.
   \\

  O.Delegation
   & 

  Provide the ability to securely delegate control. Principals that are granted
  the ``Share'' privilege shall be able to grant or revoke privileges to/from
  other principals.
  
  A special group of system administrators can be configured using ZCML to
  create a set of initial users that have all permissions. This also includes
  the permissions mapped to the ``Share'' privilege and any other permission
  that is not mapped to a privilege.

  \\

  O.Audit
   & 
  The TOE will provide the means of recording any
  security relevant events, so as to assist an
  administrator in the detection of potential attacks
  or misconfiguration of the TOE security features
  that would leave the TOE susceptible to attack, and
  also to hold users accountable for any actions
  they perform that are relevant to security.
   \\

  O.Protect
   & 
  The TOE will protect itself against external
  interference or tampering by untrusted subjects or
  attempts by untrusted subjects to bypass the TOE
  security functions.
   \\

  O.Access
   & 
  The TOE ensures that access to objects is always
  mediated by operations and guarded by permissions.
   \\

  O.Integrity
   & 
  Whenever an unhandled error within the context of a
  running transaction occurs (related or unrelated
  to security) the transaction will be rolled back
  and the system will be in the state before the
  transaction started.
   \\

  O.Attributes &  All security attributes (e.g. principal or permission
    identifiers) together must form a consistent, meaningful whole at all
    times. \\

  O.ManageRisk
   & 
  Provide the ability to manage risk by trading off functionality against risk.
  For example, we can make it easier to access the system to perform operations
  whose potential negative impact is low, but make it more difficult to access
  the system in a way that allows operations with high negative impact.
  (Especially timed authentication and identification allow to provide
  functions to unauthenticated or unidentified users with the option to
  identify or authenticate as soon as the user wants to use a more critical
  function.)
  \\
  \bottomrule
  \caption{Security Objectives for the TOE}
\end{longtable}


%___________________________________________________________________________



\section{Security objectives for the environment}

The following security objectives have been defined for the TOE environment:

\begin{longtable}[c]{lp{10cm}}
  \toprule
   Objective for the environment & Description \\
  
  \midrule\endhead

  OE.OS
   & 
  The machine and the operating system Zope is running
  on is physically secure.
   \\

  OE.Trust
   & 
  Those responsible for the TOE must be trustworthy.
   \\

  OE.Auditlog
   & 
  Administrators of the TOE must ensure that audit
  facilities are used and managed effectively. In
  particular:

  \begin{itemize}
  
    \item Appropriate action must be taken to ensure continued audit logging,
    e.g. by regular archiving of logs before audit trail exhaustion to ensure
    sufficient free space.

    \item Audit logs should be inspected on a regular basis, and appropriate
    action should be taken on the detection of breaches of security, or events
    that are likely to lead to a breach in the future.

  \end{itemize}
   \\

  OE.Network
   & 
  A network connection to the Zope services is present.
  All other network connections are secure in such a
  way that the integrity of the machine and operating
  system is preserved.
   \\

  OE.Client
   & 
  The connection between client and Zope server is secure
  in the sense that the identification and authentication
  data is not monitored or interfered.
   \\

  OE.Credential
   & 
  The user is keeping the credentials to authenticate
  secret.
  \\
  \bottomrule
  \caption{Security Objectives for the Environment}
\end{longtable}


%___________________________________________________________________________



\chapter{IT Security Requirements}


%___________________________________________________________________________



\section{TOE security requirements}


%___________________________________________________________________________



\subsection{TOE security functional requirements}

The following functional requirements identify the TOE functional requirements.
They have been drawn from the CC Part 2 functional requirements components.


%___________________________________________________________________________



\subsubsection{Class FAU: Audit data generation}


%___________________________________________________________________________



\minisec{FAU{\_}GEN.1 Audit data generation}
\begin{description}
  
  \item[FAU\_GEN.1.1] The TSF shall be able to generate an audit record of the
  following auditable events:
  \begin{itemize}
      \item Startup and shutdown of audit functions; and
      \item all auditable events for the \emph{minimum} level of audit.
  \end{itemize}

\item[FAU{\_}GEN.1.2]

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

\begin{itemize}
\item 
Date and time of the event, type of event, subject identity,
and the outcome (success or failure) of the event; and

\item For each audit event type, based on auditable event definitions
of the functional components included in the ST, \emph{the ID of the
corresponding interaction and the identity of the published object.}
\end{itemize}

\end{description}


%___________________________________________________________________________



\minisec{FAU{\_}GEN.2 User identity assocation}
\begin{description}
\item[FAU{\_}GEN.2.1]

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


\end{description}


%___________________________________________________________________________



\subsubsection{Class FDP: Data protection}


%___________________________________________________________________________



\minisec{FDP{\_}ACC.2 Complete access control}
\begin{description}

  \item[FDP{\_}ACC.2.1 ] The TSF shall enforce the \emph{Zope access control
    policy} on 1. \emph{interactions and objects} and 2. all operations among
    subjects and objects covered by the SFP.

  \item[FDP{\_}ACC.2.2] The TSF shall ensure that all operations between any
    subject in the TSC and any object within the TSC are covered by an access
    control SFP.

\end{description}


%___________________________________________________________________________



\minisec{FDP{\_}ACF.1 Security attribute based access control}
\begin{description}
\item[FDP{\_}ACF.1.1]

The TSF shall enforce the \emph{Zope access control policy} to objects
based on \emph{the interaction principal, the permission required for
the operation and the grants of the permission for that
object or it's ancestor objects}.

\item[FDP{\_}ACF.1.2]

The TSF shall enforce the following rules to determine
if an operation among controlled subjects and controlled objects is
allowed:

\begin{itemize}

\item Access is allowed, if there is no principal associated with the current
interaction. (This is equivalent of running an interaction on system level.)

\item Access is allowed, if the required permission is the special ``public''
permission.

\item Access is allowed if, for each principal associated to the interaction,
there is a privilege grant that is mapped to the required permission for either
the principal or one of the groups the principal is a member of or if the principal is a member
of the administrative system group.

\item If the object does not support sharing, access is determined by checking
the privileges of the next object in the chain of ancestors that supports
sharing. 

\item If the object does not support sharing and has no ancestors, then access
is denied.

\item Access is denied in any other case.

\end{itemize}

\item[FDP{\_}ACF.1.3]

The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: \emph{There are no additional rules.}


\item[FDP{\_}ACF.1.4]

The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: \emph{There are no additional rules.}


\end{description}

%___________________________________________________________________________
\minisec{FDP{\_}ROL.2{\_}TRANSACTIONS Advanced Rollback}
\begin{description}

\item[FDP{\_}ROL.2.1 ]

The TSF shall permit \emph{the rollback of all operations on all persistent
objects}.

\item[FDP{\_}ROL.2.2 ]


The TSF shall permit operations to be rolled back \emph{at any time before the
transaction in which the operation was performed is committed}.

\textbf{Note:} This statement does not apply to non-persistent data created
during the course of a transaction.

\end{description}



%___________________________________________________________________________
\subsubsection{Class FIA: Identification and authentication}


%___________________________________________________________________________



\minisec{FIA{\_}AFL{\_}z.1 Authentication failure handling}
\begin{description}

\item[FIA{\_}AFL{\_}z.1.1]

The TSF shall detect when there are a configurable number of consecutive
unsuccessful authentication attempts for a single login name,
with no intermediate successful attempts.

\item[FIA{\_}AFL{\_}z.1.2 ]

When the defined number of unsuccessful authentication attempts
has been surpassed, the TSF shall

\begin{itemize}
  
  \item Disable authentication against the indicated login name for a
  configurable period of time.

\end{itemize}


\end{description}


%___________________________________________________________________________



\minisec{FIA{\_}ATD.1 User attribute definition}
\begin{description}

\item[FIA{\_}ATD.1.1 ]

The TSF shall maintain the following list of security attributes
belonging to individual principals: \emph{uniqueid, credentials, privilege
grants}.

\end{description}


%___________________________________________________________________________



\minisec{FIA{\_}UAU.1 Timing of authentication}
\begin{description}

\item[FIA{\_}UAU.1.1 ]

Before the user is authenticated the TSF shall only allow \emph{those
operations where there is a privilege grant for the required permission to the
unauthenticated principal.}

\item[Note] It is possible to deny all operations to the anonymous
principal. This means that all users must login before any operations may
be performed on their behalf. Certain authentication methods require access to
operations on the Zope server and will not work if all operations are denied.
However HTTP basic auth does not require access to operations on the server
and therefore is always available.  This fulfills the terms of FIA{\_}UAU.2.


\item[FIA{\_}UAU.1.2 ]


The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions on behalf
of that user.

\end{description}


%___________________________________________________________________________


\minisec{FIA{\_}UAU.6 Re-authentication}
\begin{description}

\item[FIA{\_}UAU.6.1 ]


The TSF may re-authenticate the user under the conditions
\begin{itemize}
\item {} 
If the credentials held by the user agent have expired due to
a configurable time limit.

\item {} 
If the authenticated user does not have the required permissions to
perform a requested operation but the presentation of different
credentials might associate him with a principal that holds enough
permission grants to perform the requested operation.

\end{itemize}



\end{description}


\minisec{FIA{\_}UID.1 Timing of identification}
\begin{description}

\item[FIA{\_}UID.1.1 ]

Before the user is identified, the TSF shall allow \emph{only those operations
granted to the unauthenticated principal.}
identified.

\emph{Note:} It is possible to deny all operations to the anonymous
principal. This means that a user must login before any operations may
be performed on their behalf. The restrictions mentioned in FIA\_UAU.1.1 apply
as well.  This fulfills the terms of FIA\_UID.2


\item[FIA{\_}UID.1.2 ]


The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on behalf
of that user.



\end{description}
%___________________________________________________________________________



\minisec{FIA{\_}USB.1 User-subject binding}
\begin{description}

\item[FIA{\_}USB.1.1]


The TSF shall associate the appropriate user security
attributes with subjects acting on behalf of that user.



\end{description}


%___________________________________________________________________________



\subsubsection{Class FMT: Security management}


%___________________________________________________________________________



\minisec{FMT{\_}MOF.1 Management of security functions}
\begin{description}

\item[FMT{\_}MOF.1.1]

The TSF shall restrict the ability to \emph{determine the
behaviour of, disable, enable or modify the behaviour of} the
\emph{authentication} functions to \emph{authorized administrators}.

\item[Note]
This includes for example adding and removing principals (for example,
users) and changing the authentication schemes. Those actions can be
protected by different permissions and privileges as there are no default
values. By default only users who belong to the administrator system group are
granted those permissions.

\end{description}


%___________________________________________________________________________




\minisec{FMT{\_}MSA.1 Management of security attributes}
\begin{description}
\item[FMT{\_}MSA.1.1.grants]
    The TSF shall enforce the \emph{Zope access control policy} to restrict the
    ability to \emph{query, modify, delete, and add} the security
    attributes \emph{privilege grants} to \emph{users granted the ``Sharing''
    p
    rivilege}.
\item[FMT{\_}MSA.1.1.users]
    The TSF shall enforce the \emph{Zope access control policy} to restrict the
    ability to \emph{query, modify, delete, and add} the security
    attributes \emph{principals} to \emph{users in the administrators
    group}.

\item[FMT{\_}MSA.1.1.groups]
    The TSF shall enforce the \emph{Zope access control policy} to restrict the
    ability to \emph{query, modify, delete, and add} the security
    attributes \emph{groups} to \emph{users in the administrators group}.

\end{description}

\minisec{FMT{\_}MSA.2 Secure security attributes}

\begin{description}

\item[FMT{\_}MSA.2.1]

    The TSF shall ensure that only secure values are accepted for security
    attributes.
\end{description}

%___________________________________________________________________________



\minisec{FMT{\_}MSA.3 Static attribute initialisation}
\begin{description}

\item[FMT{\_}MSA.3.1]


The TSF shall enforce the \emph{Zope access control policy} to provide 
\emph{inherited} default values for security attributes that are used to 
enforce the SFP. 

\item[Note:] On creation of an object the creator is granted all privileges.
  Additional grants are copied from the next object in the chain of ancestors
  that supports sharing.

\item[FMT{\_}MSA.3.2 ]

The TSF shall allow \emph{administrators} to specify alternative
initial values to override the default values when an object or
information is created.

\end{description}


%___________________________________________________________________________



\minisec{FMT{\_}SMR.1 Security roles}

\begin{description}
    \item[FMT{\_}SMR.1.1]

    The TSF shall maintain the roles:
\begin{description}
\item[application-defined roles,]

\item[administration role]

Administrators can perform any operation on the system. These are users who
belong to the system administrator group defined by the
``zc:systemAdministrators'' configuration directive.

\end{description}

\item[FMT{\_}SMR.1.2]

The TSF shall be able to associate \emph{principals and groups} with roles.

\end{description}


%___________________________________________________________________________



\subsubsection{Class FPT: Protection of the TSF}


%___________________________________________________________________________



\minisec{FPT{\_}AMT.1 Abstract machine testing}
\begin{description}

\item[FPT{\_}AMT.1.1 ]


The TSF shall run a suite of tests \emph{as an offline
operation} to demonstrate the correct operation of the security
assumptions provided by the abstract machine that underlies the
TSF.



\end{description}


\minisec{FPT{\_}RVM.1 Non-bypassability of the TSP}
\begin{description}

\item[FPT{\_}RVM.1.1 ]


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



\end{description}


\minisec{FPT{\_}SEP.1 TSF domain separation}
\begin{description}

\item[FPT{\_}SEP.1.1 ]

The TSF shall maintain a security domain for its own execution that protects it
from interference and tampering by untrusted subjects.

\item[FPT{\_}SEP.1.2 ]

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

\end{description}


%___________________________________________________________________________



\minisec{FPT{\_}STM.1 Reliable time stamps}
\begin{description}

\item[FPT{\_}STM.1.1]


The TSF shall be able to provide reliable time stamps for its own use.



\end{description}


%___________________________________________________________________________



\subsection{TOE security assurance requirements}

The evaluation assurance level chosen for this evaluation is EAL 1.

The following TOE assurance requirements drawn from CC Part 3 are valid:

\begin{longtable}[c]{lp{7cm}p{3cm}}
  \toprule
  Identification & Description & Direct dependencies\\
  \midrule \endhead

  \textbf{ADO} & Delivery and Operation &  \\
  ADO{\_}IGS.1 & Installation, generation and start-up & AGD{\_}ADM.1 \\
  
  \textbf{ADV} & Development &  \\
  ADV{\_}FSP.1 & Informal Functional specification & ADV{\_}RCR.1 \\

  ADV{\_}RCR.1 & Representation correspondence: Information correspondence
  demonstration & None \\ 

  ADV{\_}SPM.1 & Informal TOE security policy model & ADV\_FSP.1 \\

  \textbf{AGD} & Guidance documents &  \\
  AGD{\_}ADM.1 & Administrator guidance & ADV{\_}FSP.1 \\
  AGD{\_}USR.1 & User guidance (for developers) & ADV{\_}FSP.1 \\
  \textbf{ATE} &  &  \\ 
  ATE{\_}IND.1 & Independent testing - conformance & ADV{\_}FSP.1 AGD{\_}ADM.1 AGD{\_}USR.1 \\


  \bottomrule
  \caption{TOE Assurance Requirements}
            
\end{longtable}


%___________________________________________________________________________



\section{Security requirements for the IT environment}

The following security requirements exist for the IT environment:

\begin{itemize}

  \item The operating system is Linux. All known security patches must have
    been installed.

  \item The Python Version is 2.4.3

  \item The ZODB storage is FileStorage or FileStorage through a ZEO server.

  \item The client software must support ``protected authentication feedback'',
      to at least not echo a user's credentials in plain text (FIA{\_}UAU.7).

  \item The TOE can only be accessed through a ``trusted path'' using secure
      proxies, such as an HTTPS proxy like Apache with SSL, or Pound. Users are
      taught to make correct use of secure channels (e.g. accepting only valid
      SSL certificates). 

  \item If external IT systems are used, a trusted channel between the TOE and
      those systems must be provided by the TOE host environment.  For example,
      while the TOE may communicate with clients on a public network through a
      specific port allowed through a firewall, all communication with other IT
      systems should be over a (virtual) private network.

\end{itemize}
%___________________________________________________________________________

\chapter{TOE summary specification}


\section{TOE security functions}  \label{toe-sec-funcs}


The major functions implemented by the TOE are:


%___________________________________________________________________________


\subsection{Protection}

The protection subsystem is responsible for controlling the access of subjects
to objects.  It does this through the use of security proxies.  Any non-basic
objects that an interaction accesses is wrapped in a security proxy.  All
operations on these non-basic objects are performed through the security
proxies. Security proxies use the authorization system to decide whether access
is allowed.  Any non-basic results of operations performed through security
proxies are security proxied.

%___________________________________________________________________________



\subsection{Authentication}

Within the scope of this certification, Zope provides authentication using
HTTP basic authentication and a session/cookie-based authentication mechanism.
Credentials can be configured and stored using the configuration system and/or
in the ZODB using the ``Pluggable Authentication Utility''.

%___________________________________________________________________________



\subsection{Authorization / Access control}

To determine whether an operation under a given subject is allowed, Zope has an
authorization subsystem (aka access control). The authorization subsystem uses
pluggable policies to allow the implementation of different rule sets. Zope
provides a default security policy called ``zopepolicy''. The security policy
considered for this certification is called ``sharing policy''

Policies implement a method `checkPermission' to determine whether the
requested access is allowed or not. Policies define the information required to
make authorization decisions.  Policies therefore can be implemented to extend
or reduce the current functionality.

The ``sharing policy'' considers users, groups, permission-to-privilege
mappings, privilege grants, and the context object to make a decision.
Privileges can be granted to principals or groups.  Subjects can consider
multiple principals, for example if the execution of untrusted code is
involved.

If no principal is associated with a interaction, the interaction is allowed to
perform any operation. However, the publisher component is required to
associate a special anonymous principal if no user has been authenticated.

Every principal is always granted the ``zope.Public'' permission which can't be
denied by any means.

%___________________________________________________________________________


\subsection{Configuration}

The configuration system is used to provide definitions for security
attributes. It is used to define permissions, privileges,
permission-to-privilege mappings, initial principals and other security policy
relevant data.

It can be accessed via the Python API, the web interface and
through ZCML configuration files.

The configuration system takes care that any operation made to the security
relevant data does not compromise the systems integrity by disallowing
conflicting declarations.

\subsection{Auditing}

Zope provides an auditing system that listens for events within Zope according
to the SFRs described above. It is implemented using the event framework of
Zope 3 to subscribe to the audit relevant events and log them appropriately.
The infrastructure provided (event listener + logger) satisfies the
requirements as described in FAU{\_}GEN.1 and FAU{\_}GEN.2.

Zope relies on the operating system to deliver reliable time stamps for the
audit log.


%___________________________________________________________________________



\subsection{Transaction management}

In Zope user data is stored on persistent objects. The transaction machinery
provides ACID compatible transactions (atomic, consistent, isolated, durable)
for any operation on the user data.

%___________________________________________________________________________

\subsection{Publication / Server}

The publisher allows users to communicate with the Zope server through a
network, using standard protocols and client software like HTTP and web
browsers or FTP and FTP clients. Within the ST the publisher is the only valid
entry point to communicate with a Zope 3 application as it also is the
starting point for the protection subsystem to be involved. As the publisher
is the only valid entry point it is not allowed to have any other applications
access the database server (ZEO) directly.

The publisher is extensible to allow support for further protocols.

To support FIA{\_}UAU.1 the implementation of a protocol includes the ability
to communicate with a user for requesting authentication data. The ability to
present credentials is specific to the used protocol and clients. By default
HTTP basic auth, session/cookie authentication and FTP authentication are
supported.

To support FIA{\_}USB.1, the publisher also returns the credentials to Zope and
calls the authentication subsystem to validate this data and binds the
authenticated principal to the running interaction.

%___________________________________________________________________________


\subsection{Automated tests}

Zope provides a suite of automated tests that allow the user to ensure that the
security functionality in the TOE is consistent with the tests. Those tests are
run in offline mode.


%___________________________________________________________________________



\subsection{Python environment}

As Zope relies on Python and the host environment to provide reliable time
stamps. Changes to the external clock are not audited within the system as we
regard them as beeing out of scope.  Therefore external log mechanisms (such
as syslog) should be consulted to detect those changes. (FPT{\_}STM.1)

%___________________________________________________________________________


\section{Assurance measures}

%___________________________________________________________________________


\subsection{AM{\_}ADO: DELIVERY AND OPERATION}

A document describing the delivery and operation of the TOE will be provided.


%___________________________________________________________________________


\subsection{AM{\_}ADV: DEVELOPMENT}

A functional specification, an RCR document and an informal security policy model
(ADV\_SPM.1) will be provided.

%___________________________________________________________________________



\subsection{AM{\_}AGD: GUIDANCE DOCUMENTS}

The guidance documents AGD{\_}ADM and AGD{\_}USR will be provided.


%___________________________________________________________________________



\subsection{AM{\_}ATE: TESTS}

No deliverable. Only independend testing from the evaluator is needed.


%___________________________________________________________________________



\chapter{PP claims}

No PP compatibility is beeing claimed.


%___________________________________________________________________________


\chapter{Rationale}


%___________________________________________________________________________



\section{Security objectives rationale}

The following table shows that all threats and assumptions are covered
by a security objectives. 

  \begin{longtable}{rRRRRRRRRRRRRRRR}
    \toprule
              & T.IA  & T.Perm &T.Operation&T.AuditFake& T.Inconsistent&T.Transaction&T.Timestamps & T.Host & A.OS & A.Admin & A.Network & A.Client & A.Credential  \\
    \midrule\endhead
O.IA         &  \oh  &       &            &            &               &             &             &        &      &       \\
O.Delegation &       &   \oh &            &            &               &             &             &        &      &        \\
O.Audit      & \oh   &   \oh &     \oh    &            &               &             &             &        &      &        \\
O.Protect    &       &       &            &    \oh     &               &             &             &        & \oh  &        \\
O.Access     &       &       &      \oh   &            &               &    \oh      &             &   \oh  &      &        \\
O.Integrity  &       &       &            &            &  \oh          &             &             &        &      &        \\
O.Attributes &       &       &            &            &  \oh          &             &             &        &      &        \\
O.ManageRisk &   \oh &       &            &            &               &             &             &        &      &        \\
\midrule
OE.OS        &       &       &            &            &               &             &    \oh      &        &  \oh &         &         &            &          \\
OE.Trust     &       &       &            &            &               &             &             &        &      &  \oh    &         &            &            \\
OE.Auditlog  &       &       &            &            &               &             &             &        & \oh  &         &         &            &                   \\  
OE.Network   &       &       &            &            &               &             &             &        &      &         &  \oh    &            &                   \\   
OE.Client    &       &       &            &            &               &             &             &        &      &         &         &    \oh     &                   \\
OE.Credential&       &       &            &            &               &             &             &        &      &         &         &            &    \oh    \\ 
\bottomrule
  \caption{Mapping of Threats and Assumptions to Security Objectives}
  \label{tab-SOR}
\end{longtable}

The following list explains why the objectives cover
the threats and assumptions.

\begin{description}
  
  \item[O.IA:] This security objective is necessary to counter the threat
  \textbf{T.IA} because it requires that users must be accurately identified
  and authenticated or incorporate the anonymous principal.

  \item[O.Delegation:] This security objective is necessary to counter the
  threat \textbf{T.Perm} because a user must only be able to delegate the permissions
  he is allowed to delegate. It must not be possible for him to gain any extra
  permissions.
  
  \item[O.Audit:] This security objective is necessary to detect and recover
    from most threats: \textbf{T.IA, T.Perm and T.Operation} as those events
    are logged by the audit log.
  
  \item[O.Protect:] This security objective is necessary to counter the threat
  \textbf{T.AuditFake} because it protects the audit data generation function
  and thereby prevents logging of false information. It also helps to covers
  the assumption \textbf{A.OS} because self-protection mechanisms help to
  dtect security problems in the runtime environment.
  
  \item[O.Access:] This security objective is necessary to counter the threat
  \textbf{T.Operation} because it prevents performing operations on an object
  without having the correct permission. It also counters the threat
  \textbf{T.Host} because functions are objects and thereby protected.

  O.Access also counters the threat \textbf{T.Transaction} because transaction
  managing functions are also objects and therefore protected.

  \item[O.Integrity:] This security objective is necessary to counter the
    threat \textbf{T.Inconsistent} because it prevents that any data will be
    written if an unhandled error occurs.
  
  \item[O.Attributes:] This security objective is necessary to counter the
    threat \textbf{T.Inconsistent} because it prevents an attacker from
    setting inconsistent security attributes from which he could gain more
    access than intended.

  \item[O.ManageRisk:] This security objective is necessary to counter the
  threat \textbf{T.IA} because it makes it less likely that an attacker
  impersonates a principal which allows operations with high negative impact
  since those principals are better protected.

  \item[OE.OS:] This security objective is necessary to both counter the
  threat \textbf{T.Timestamps} and cover the assumption \textbf{A.OS} because
  it asserts that the machine and the operating system the TOE is running on
  are physically secure. This means an attacker cannot access the machine
  directly, i.e. around Zope.

  \item[OE.Auditlog:] This security objective covers the assumption
  \textbf{A.OS}. To keep the operating system secure and detect possible
  intrusions it is vital to continuously monitor the audit log. It is also
  important to keep the Auditlog in a safe place to have enough information to
  recover from an attack.

  \item[OE.Network:] This security objective covers the assumptions
  \textbf{A.Network} because it asserts that all
  network !(!5
  compromising the integrity.

  \item[OE.Client:] This security objective covers the assumption
  \textbf{A.Client} because it makes sure that the identification and
  authentication data is not monitored or interfered.

  \item[OE.Credential:] This security objective covers the assumption
  \textbf{A.Credential} because it demands that the user is keeping the
  credentials to authenticate secret.
  
\end{description}
%___________________________________________________________________________



\section{Security requirements rationale}

The following table shows that all objectices are covered by security
functions.

\begin{longtable}{rRRRRRRRR}
        \toprule
                            & O.IA & O.Delegation & O.Audit & O.Protect & O.Access & O.Integrity & O.Attributes & O.ManageRisk \\
        \midrule\endhead

FAU\_GEN.1                  &      &              & \oh     &           &          &             &              &              \\
FAU\_GEN.2                  &      &              & \oh     &           &          &             &              &              \\
FDP\_ACC.2                  &      & \oh          &         &           & \oh      &             &              &              \\
FDP\_ACF.1                  &      &              &         &           &  \oh     &             &              &              \\
FDP\_ROL.2\_Transactions    &      &              &         &           &          &   \oh       &              &              \\
FIA\_AFL\_z.1               &      &              &         &   \oh     &          &             &              &              \\
FIA\_ATD.1                  & \oh  &  \oh         &   \oh   &           & \oh      &             &              &              \\
FIA\_UAU.1                  & \oh  &              &         &           &          &             &              &              \\
FIA\_UAU.6                  & \oh  &              &         &           &          &             &              &              \\
FIA\_UID.1                  & \oh  &              &         &           &          &             &              &              \\
FIA\_USB.1                  & \oh  &              &         &           &          &             &              &              \\
FMT\_MOF.1                  &      &              &         &  \oh      &          &             &              &              \\
FMT\_MSA.1                  & \oh  &  \oh         &         &           &          &             &              &              \\
FMT\_MSA.2                  &      &              &         &           &          &             &  \oh         &              \\  
FMT\_MSA.3                  &      &              &         & \oh       &          &             &  \oh         &              \\
FMT\_SMR.1                  &      &              &         &           &          &             &              &              \\
FPT\_AMT.1                  &      &              &         & \oh       &          &             &              &              \\
FPT\_RVM.1                  &      &              &         &           &  \oh     &             &              &              \\
FPT\_SEP.1                  &      &              &         &   \oh     &          &             &              &   \oh        \\
FPT\_STM.1                  &      &              &  \oh    &           &          &             &              &              \\
 \bottomrule
 \caption{Mapping of Security Objectives to Security Functional Requirements}
\end{longtable}

\subsection{SFR component dependency analysis}

\begin{longtable}{rp{8cm}}
        \toprule
        SFR                 &   Depends on  \\
        \midrule\endhead
FAU\_GEN.1                  &   FPT\_STM.1   \\
FAU\_GEN.2                  &   FAU\_GEN.1, FIA\_UID.1 \\
FDP\_ACC.2                  &   FDP\_ACF.1 \\
FDP\_ACF.1                  &   FDP\_ACC.1, FMT\_MSA.3 \\
FDP\_ROL.2\_Transactions    &   -- \\
FIA\_AFL\_z.1               &   FIA\_UAU.1 \\
FIA\_ATD.1                  &   -- \\
FIA\_UAU.1                  &   FIA\_UID.1 \\
FIA\_UAU.6                  &   -- \\
FIA\_UID.1                  &   -- \\
FIA\_USB.1                  &   FIA\_ATD.1 \\
FMT\_MOF.1                  &   FMT\_SMR.1 \\
FMT\_MSA.1                  &   FMT\_SMR.1 \\
FMT\_MSA.2                  &   ADV\_SPM.1, FMT\_MSA.1, FMT\_SMR.1 \\
FMT\_MSA.3                  &   FMT\_MSA.1, FMT\_SMR.1 \\
FMT\_SMR.1                  &   FIA\_UID.1 \\
FPT\_AMT.1                  &   -- \\
FPT\_RVM.1                  &   -- \\
FPT\_SEP.1                  &   -- \\
FPT\_STM.1                  &   -- \\
\bottomrule
   \caption{SFR Dependency Analysis}
\end{longtable}

All dependencies required by the chosen SFRs are covered. 

\subsection{O.IA --- Identification and authentication}

    A central part of the security machinery within the TOE is the correct
    identification and authentification of users.

    This is covered by the activities:

    \begin{description}
        \item[Asking for and validating a user's credentials:]

            The TOE holds information to uniquely identify a principal and its
            required credentials (FIA\_ATD.1).
            
            The TOE presents the user with a prompt to supply his credentials
            if an operation requires an identified and authenticated principal (FIA\_UAU.1, FIA\_UID.1)

            Depending on the communication channel, the system selects a
            suitable authentication mechanism to ask a user for his
            credentials. 

            If an authenticated user does not have enough permission grants to
            perform an operation, he might get the chance to authenticate with
            other credentials. (FIA\_UAU.6)

            If the credentials stored at the user agent expire (e.g.  cookies
            in a web browser), the user will be asked to represent his
            credentials before performing any further operation. (FIA\_UAU.6)

        \item[Binding users to the correct principals:]

            The TOE allows users to interact with the system without presenting
            credentials by binding unauthenticated users to the ``Unauthenticated ''
            principal. This allows parts of applications to be accessible without
            presenting any credentials. (FIA\_UAU.1)

            Once a user has been identified and authenticated, the subject of
            the operation is bound to the user by selecting the correct
            principal. (FIA\_USB.1)

        \item[Managing required security attributes:]

            The TOE manages the required security attributes (permission
            grants, credentials, \dots). Special permissions are required
            to read or write certain security attributes. (FMT\_MSA.1)

        \item[Associating principals with the correct security attributes:]

            This is covered by FIA\_ATD.1 and FIA\_USB.1

    \end{description}

\subsection{O.Delegation  --- Securely delegate control}

    Changing permission grants allows the delegation of permission
    grants to other users. Administrators that have grants for all
    permissions introduce new users to the system by delegating the required
    permissions to them (e.g. via privilege or direct permission grants).

    Delegating control is a normal operation performed on the TOEs objects. To
    grant a permission the sharing prililedge is required. (FMT\_ATD.1)

    Those operations are securely managed because they are covered by the TSF
    (FDP\_ACC.2) and follow special rules regarding the management of security
    attributes. (FMT\_MSA.1)

\subsection{O.Audit --- Provide a reliable security audit trail}

    The TOE shall provide functionality to generate audit data (FAU\_GEN.1,
    FAU\_GEN.2).

    The TOE includes reliable time stamps to guarantee reasonable data to be
    logged (FPT\_STM.1) and connects all events with the relevant user
    attributes. (FIA\_ATD.1)

\subsection{O.Protect --- Protect the TOE from external tampering}

    The TOE disallows tampering with the system. Most situations have to be
    avoided due to correct appliance of the environmental requirements though.

    As the TOE is normally run with access through open communication channels
    like the internet, credentials very likely might be compromised by brute
    force attacks. This is avoided by applying FIA\_AFL\_z.1.

    Changing the behaviour of security functions is a critical operation.
    Therefore a set of well known permissions and privileges are established to
    easily identify people that are able to change any security relevant
    behaviour. (FMT\_MOF.1)
    
    In the case of data loss, failure of subsystems or unexpected situations,
    the usage of FMT\_MSA.3 allows the system to stay in the most secure state
    possible. Asserting restrictive default values for security attributes
    avoids permission elevation and results in a better protected TOE.
    
    Using abstract machine tests, the system is able to check if the security
    code has been modified and does not hold to the assumptions of the security
    machinery anymore. (FPT\_AMT.1)

    The TOE holds a special domain for running untrusted code that prevents 
    external entities from directly modifing or calling any security relevant
    attributes or functions. (FPT\_SEP.1)

\subsection{O.Access --- Mediate every access to objects}

    Mediating every access to an object through operations is another major
    objective to enforce the TSP. (FDP\_ACC.2)

    A set of attributes and rules is used to describe how to apply those
    attributes for deriving an access decision. (FDP\_ACF.1, FIA\_ATD.1)  

    To ensure the non-bypassability of the TSP a special paradigm is used:
    Every access has to pass a single entry point (the Zope publisher) who
    wraps every object from the TOE with a so called ``security proxy''. Any
    access from an interaction to an object from thereon will be mediated by
    the proxy, who in turn activates the protection subsystem. (FPT\_RVM.1)
    
\subsection{O.Integrity --- Ensure faultless data}

    Providing an ACID compatible transaction management system that allows
    secure rollback from a failed transaction satisfies the objective to have
    the system keep its integrity. (FDP\_ROL.2\_Transactions)

    The rollback is performed by the TOE automatically as soon as an error is
    encountered and not handled by any application logic.

\subsection{O.Attributes --- Ensure consistent security attributes}

    To assure an enduring consistent state of all security attributes we
    enforce the security policy model upon any changes to security attributes.
    (FMT\_MSA.2) Additionally static security attribute initialization assures
    a predictable and secure state if no specific attributes are given.
    (FMT\_MSA.3)

\subsection{O.ManageRisk --- Provide choice of flexibility versus security}
    
    Code can be run either within the trusted or untrusted security domains of
    the TOE. Installing code in the trusted security domain requires an
    external entity that has access to the physical secure host to install
    software into the TOE. This allows developers and administrators to trade
    off between functionality of their code and the level of trust they have to
    agree on when installing a developer's extensions. FPT\_SEP.1 supports the
    distinction between the trusted and untrusted domain.

\newpage

\section{TOE summary specification rationale}

\subsection{Security functions rationale}

\begin{longtable}{rRRRRRRRRRR}
        \toprule
                    & Protection & Authentication & Authorization & Auditing & Configuration & Transaction management & Publication/Server & Automated Tests & Python Environment \\
        \midrule\endhead
FAU\_GEN.1          &            &                &               & \oh      &               &                        &                    &                 &                    \\   
FAU\_GEN.2          &            &                &               & \oh      &               &                        &                    &                 &                    \\   
FDP\_ACC.2          & \oh        &                &               &          &               &                        & \oh                &                 &                    \\   
FDP\_ACF.1          &            &                &  \oh          &          &               &                        &                    &                 &                    \\   
FDP\_ROL.2\_TRANSACTIONS
                    & \oh        &                &  \oh          &          &               & \oh                    &                    &                 &                    \\   
FIA\_AFL\_z.1       &            &  \oh           &               &          &               &                        & \oh                &                 &                    \\   
FIA\_ATD.1          &            &                &               &          & \oh           &                        &                    &                 &                    \\   
FIA\_UAU.1          &            &                &               &          &               &                        & \oh                &                 &                    \\   
FIA\_UAU.6          &            &  \oh           &               &          &               &                        & \oh                &                 &                    \\   
FIA\_UID.1          &            &                &               &          &               &                        & \oh                &                 &                    \\   
FIA\_USB.1          &            &                &               &          &               &                        &  \oh               &                 &                    \\   
FMT\_MOF.1          & \oh        &  \oh           &  \oh          &          & \oh           &                        &                    &                 &                    \\   
FMT\_MSA.1          &            &                &  \oh          &          & \oh           &                        &                    &                 &                    \\   
FMT\_MSA.2          &            &                &               &          & \oh           &                        &                    &                 &                    \\   
FMT\_MSA.3          &            &                &  \oh          &          & \oh           &                        &                    &                 &                    \\   
FMT\_SMR.1          &            &                &  \oh          &          & \oh           &                        &                    &                 &                    \\   
FPT\_AMT.1          &            &                &               &          &               &                        &                    &    \oh          &                    \\   
FPT\_RVM.1          & \oh        &                &               &          &               &                        &  \oh               &                 &                    \\   
FPT\_FLS.1          &            &                &               &          &               &     \oh                &                    &                 &                    \\   
FPT\_SEP.1          &  \oh       &                &               &          &               &                        &                    &                 &                    \\ 
FPT\_STM.1          &            &                &               &          &               &                        &                    &                 &   \oh              \\       
    \bottomrule
    \caption{Security Functions Rationale} 

\end{longtable}

\subsubsection{Suitability of SF to meet the SFRs}

\minisec{FDP\_ACC.2 --- Complete Access Control}

Complete access control is achieved by the \textbf{Protection} subsystem. The
\textbf{Publication} subsystem serves as a single entry point to the Zope 3
application which wraps all published objects into security proxies.

When an interaction accesses a proxied object, the protection subsystem
becomes effective and regulates access.


\minisec{FDP\_ROL.2\_TRANSACTIONS --- Advanced Rollback}

The \textbf{Transaction management} of ZODB allows rollback of transaction. The
\textbf{Protection} and \textbf{Authorization} subsystems (in place by the
complete access control) will deny the unauthorized use of those management
functions. As a result only the subject of a transaction is able to roll back
it's corresponding transaction.

As transactions are only valid within a single subject (interaction), there is no
possibility to cancel other transactions through the use of the
\textbf{Publication} subsystem.

\minisec{FIA\_AFL\_z.1 --- Authentication Failure Handling}

AFL is handled in cooperation of the \textbf{Authentication} and
\textbf{Publication} subsystem. The \textbf{Publication} subsystem identifies
individual authentication trials and uses the authentication subsystem to
update the security attributes that store the information about failed
requests. The split of this functionality is needed as the
\textbf{Authentication} subsystem may not be able to distinguish two requests
to be different user initiated requests or started off at another point in the
application.
  

\minisec{FIA\_UAU.1, FIA\_UID.1 --- Timing of authentication and identification}

The \textbf{Publication} subsystem detects provided credentials and existing
sessions on the implemented network protocols. It then either identifies and
authenticates the user for this subject or uses the anonymous principal to
perform the requested operation. If the anonymous principal is not allowed to
perform the requested operation, the \textbf{Publication} subsystem challenges
the user to provide sufficient credentials for authentication and
identification.

The \textbf{Publication} and \textbf{Authentication} subsystems work together
to identify a meaningful way of asking a user for his credentials. 

The \textbf{Authentication} subsystem can then implement different schemes for
validating the credentials that the \textbf{Publication} system retrieved from
the user.

The choice of retrieval and verification can depend on the network protocol
(FTP, HTTP) and the strength of authentication that is requested (e.g. password,
client certificates).

\minisec{FIA\_UAU.6 --- Re-authentication}

If an operation could not be performed due to missing permission grants, the
\textbf{Publication} subsystem may -- instead of denying further operation --
ask the user to provide other credentials to authenticate for a different
principal.

\emph{Note:} This is implemented by the same scheme that is used to initially
retrieve credentials from a user when the operation could not be performed by
the anonymous principal.

\minisec{FIA\_USB.1 --- User-Subject Binding}

When the \textbf{Publication} system sets up to perform an operation, it
creates a context of ``interaction''. This interaction is always associated
with (at least) one principal. If a principal was authenticated during the
creation of this context, the interaction gets associated with this principal.
Otherwise the unauthenticated principal will be bound to the subject.

Binding a principal to an interaction transitively associates the required security
attributes (e.g. permission grants) to this interaction.

\minisec{FMT\_MOF.1 --- Management of Security Functions}

Management of security functions happens by different physical ways (editing
configuration files, working with the web interface, writing scripts) that are
all addressing a single security configuration API that is offered by the
\textbf{Configuration}, \textbf{Authentication} and \textbf{Authorization}
subsystems. Access to those subsystems is -- as always -- covered by the
complete access control policy and enforced by the \textbf{Protection}
subsystem.

\minisec{FMT\_MSA.1 --- Management of Security Attributes}

Managing security attributes is a normal operation and therefore protected.

\minisec{FMT\_MSA.2 --- Secure Security Attributes}

The \textbf{Configuration} subsystems API for managing security functions and
attributes perform consistency checks upon the change of any security
attributes. This includes for example the check of dependencies that the
removal of principals also has the effect of removal of all dependent
permission grants and denials. 

Also only already existing identifiers (user names, permission names) may 
be used as references.

\minisec{FMT\_MSA.3 --- Static Attribute Initialization}

A set of fixed rules that are used whenever an attribute definition is missing
realize the static attribute initialisation. These rules are implemented in the
different subsystems (\textbf{Authorization} and \textbf{Configuration})
whenever a specific attribute would be used or defined.

\minisec{FMT\_SMR.1 --- Security roles}

The \textbf{Authorization} system resolves privileges that users hold into
permissions they are granted or denied. The configuration system holds the
definition of what users possess and how privileges are mapped to permissions.

Pre-defined privilege/permission/ are delivered with the certified Zope
configuration to match the Administrator, Grantor and User roles.

\minisec{FPT\_RVM.1 --- Non-bypassability of the TSP}

The concept of the \textbf{Protection} system is to put a layer of protection
around any object that is beeing accessed from an interaction. It is designed
in a transitive manner that it will not allow any computation to bypass it.

\minisec{FPT\_SEP.1 --- TSF domain seperation}

The \textbf{Protection} subsystem allows code that has been brought to the
system via installation on the host filesystem to remove security proxies. This
results in the ability (for performance or functional reasons) to write code
that calls system functions and internal APIs without disturbing the protected
code areas.

When data is passed from the trusted domain into another part of the system,
the Protection system will prevent the elevation of privileges by assuring that
the layer of security proxies is installed and effective.

\subsection{Assurance measures}

The assurance measures are selected in accordance to EAL 1. Additionally due to
the selection of FMT\_MSA.2 the document ADV\_SPM has been selected.

%___________________________________________________________________________

\subsection{Choice of TOE security assurance requirements}

The choice of assurance requirements is based on the analysis of the security
objectives for the TOE and on functional requirements defined to meet these
objectives.

The assurance level is \textbf{EAL 1}.

%___________________________________________________________________________


\section{Evaluation assurance level rationale}

The Zope development community recognizes the need of mature and well defined
security functions by its users.

Therefore to meet this requirement the decision for an entry level evaluation
was made on the basis of resource constraints of available developers and
budget.

Additionally an entry level evaluation gives a glance to the community how a
certification may effect Zope's degree of documentation and stabilize the good
security history even more. Eventually this raises interest in Zope 3 for
projects that have strong requirements in respect to security and do seek free
alternatives to closed source projects.

It is intended to show that mature open source projects can outperform
proprietary systems not only on pure functional and monetary aspects but also
in domains that are typically governed by proprietary systems. Performing a
well known standardized evaluation also substantiates confidence and trust that
Zope as a free software project receives by it's users.

%___________________________________________________________________________



\chapter{Glossary}

\begin{description}

  \item[CC] Common Criteria (referenced as CC])
  \item[SF] Security Function
  \item[SFP] Security Function Policy
  \item[SFR] Security Functional Requirement
  \item[ST] Security Targets
  \item[TOE] Target of Evaluation
  \item[SVN] Subversion; A source code management system, used for managing the Zope source code.
  \item[TSF] TOE Security Functions

\end{description} 

%___________________________________________________________________________


\end{document}
