[Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.tex -
Moving to use tex from now on. This was generated by rst2html
and is quite ugly right now.
Christian Theune
ct at gocept.com
Tue Apr 19 06:38:02 EDT 2005
Log message for revision 30035:
- Moving to use tex from now on. This was generated by rst2html and is quite ugly right now.
Changed:
A Zope3/trunk/doc/security/SecurityTarget.tex
-=-
Added: Zope3/trunk/doc/security/SecurityTarget.tex
===================================================================
--- Zope3/trunk/doc/security/SecurityTarget.tex 2005-04-19 04:26:03 UTC (rev 30034)
+++ Zope3/trunk/doc/security/SecurityTarget.tex 2005-04-19 10:38:02 UTC (rev 30035)
@@ -0,0 +1,3168 @@
+\documentclass[10pt,a4paper,english]{article}
+\usepackage{babel}
+\usepackage{shortvrb}
+\usepackage[latin1]{inputenc}
+\usepackage{tabularx}
+\usepackage{longtable}
+\setlength{\extrarowheight}{2pt}
+\usepackage{amsmath}
+\usepackage{graphicx}
+\usepackage{color}
+\usepackage{multirow}
+\usepackage{ifthen}
+\usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue]{hyperref}
+\usepackage[DIV12]{typearea}
+%% generator Docutils: http://docutils.sourceforge.net/
+\newlength{\admonitionwidth}
+\setlength{\admonitionwidth}{0.9\textwidth}
+\newlength{\docinfowidth}
+\setlength{\docinfowidth}{0.9\textwidth}
+\newlength{\locallinewidth}
+\newcommand{\optionlistlabel}[1]{\bf #1 \hfill}
+\newenvironment{optionlist}[1]
+{\begin{list}{}
+ {\setlength{\labelwidth}{#1}
+ \setlength{\rightmargin}{1cm}
+ \setlength{\leftmargin}{\rightmargin}
+ \addtolength{\leftmargin}{\labelwidth}
+ \addtolength{\leftmargin}{\labelsep}
+ \renewcommand{\makelabel}{\optionlistlabel}}
+}{\end{list}}
+% begin: floats for footnotes tweaking.
+\setlength{\floatsep}{0.5em}
+\setlength{\textfloatsep}{\fill}
+\addtolength{\textfloatsep}{3em}
+\renewcommand{\textfraction}{0.5}
+\renewcommand{\topfraction}{0.5}
+\renewcommand{\bottomfraction}{0.5}
+\setcounter{totalnumber}{50}
+\setcounter{topnumber}{50}
+\setcounter{bottomnumber}{50}
+% end floats for footnotes
+% some commands, that could be overwritten in the style file.
+\newcommand{\rubric}[1]{\subsection*{~\hfill {\it #1} \hfill ~}}
+\newcommand{\titlereference}[1]{\textsl{#1}}
+% end of "some commands"
+\title{Zope X3 Security Target for EAL 1 ({\$}Rev: 30023 {\$} - Draft)}
+\author{}
+\date{}
+\hypersetup{
+pdftitle={Zope X3 Security Target for EAL 1 ({\$}Rev: 30023 {\$} - Draft)},
+pdfauthor={Christian Theune {\textless}ct at gocept.com{\textgreater};Steve Alexander {\textless}steve at catbox.net{\textgreater};Jim Fulton {\textless}jim at zope.com{\textgreater}}
+}
+\raggedbottom
+\begin{document}
+\maketitle
+
+%___________________________________________________________________________
+\begin{center}
+\begin{tabularx}{\docinfowidth}{lX}
+\textbf{Version}: &
+ 30023 (Draft) \\
+\textbf{Date}: &
+ 2005-04-18 15:47:51 +0200 (Mon, 18 Apr 2005) \\
+\textbf{Author}: &
+ Christian Theune {\textless}ct at gocept.com{\textgreater} \\
+\textbf{Author}: &
+ Steve Alexander {\textless}steve at catbox.net{\textgreater} \\
+\textbf{Author}: &
+ Jim Fulton {\textless}jim at zope.com{\textgreater} \\
+\textbf{DocumentID}: &
+ SecurityTarget.txt 30023 2005-04-18 13:47:51Z zagy \\
+\end{tabularx}
+\end{center}
+
+\setlength{\locallinewidth}{\linewidth}
+
+\hypertarget{contents}{}
+\pdfbookmark[0]{Contents}{contents}
+\subsection*{~\hfill Contents\hfill ~}
+\begin{list}{}{}
+\item {} \href{\#document-history}{Document History}
+
+\item {} \href{\#st-introduction}{ST introduction}
+\begin{list}{}{}
+\item {} \href{\#st-identification}{ST identification}
+
+\item {} \href{\#st-overview}{ST overview}
+
+\item {} \href{\#iso-iec-15408-cc-conformance}{ISO/IEC 15408 (CC) Conformance}
+
+\end{list}
+
+\item {} \href{\#toe-description}{TOE description}
+\begin{list}{}{}
+\item {} \href{\#overview}{Overview}
+
+\item {} \href{\#toe-definition}{TOE definition}
+
+\item {} \href{\#toe-development-and-production}{TOE Development and Production}
+
+\item {} \href{\#toe-life-cycle}{TOE Life Cycle}
+
+\item {} \href{\#toe-boundaries}{TOE Boundaries}
+\begin{list}{}{}
+\item {} \href{\#physical-boundaries}{Physical Boundaries}
+
+\item {} \href{\#toe-logical-boundaries}{TOE Logical Boundaries}
+
+\end{list}
+
+\end{list}
+
+\item {} \href{\#toe-security-environment}{TOE security environment}
+\begin{list}{}{}
+\item {} \href{\#assets}{Assets}
+
+\item {} \href{\#subject}{Subject}
+
+\item {} \href{\#operations}{Operations}
+
+\item {} \href{\#assumptions-about-the-environment}{Assumptions (about the environment)}
+
+\item {} \href{\#threats}{Threats}
+
+\item {} \href{\#organisational-security-policies}{Organisational security policies}
+
+\end{list}
+
+\item {} \href{\#security-objectives}{Security objectives}
+\begin{list}{}{}
+\item {} \href{\#security-objectives-for-the-toe}{Security objectives for the TOE}
+
+\item {} \href{\#security-objectives-for-the-environment}{Security objectives for the environment}
+
+\end{list}
+
+\item {} \href{\#security-requirements}{Security requirements}
+\begin{list}{}{}
+\item {} \href{\#toe-security-requirements}{TOE security requirements}
+\begin{list}{}{}
+\item {} \href{\#toe-security-functional-requirements}{TOE security functional requirements}
+\begin{list}{}{}
+\item {} \href{\#class-fau-audit-data-generation}{Class FAU: Audit data generation}
+\begin{list}{}{}
+\item {} \href{\#fau-gen-1-audit-data-generation}{FAU{\_}GEN.1 Audit data generation}
+
+\item {} \href{\#fau-gen-2-user-identity-assocation}{FAU{\_}GEN.2 User identity assocation}
+
+\end{list}
+
+\item {} \href{\#class-fdp-data-protection}{Class FDP: Data protection}
+\begin{list}{}{}
+\item {} \href{\#fdp-acc-2-complete-access-control}{FDP{\_}ACC.2 Complete access control}
+
+\item {} \href{\#fdp-acf-1-security-attribute-based-access-control}{FDP{\_}ACF.1 Security attribute based access control}
+
+\item {} \href{\#fdp-etc-2-export-of-user-data-with-security-attributes}{FDP{\_}ETC.2 Export of user data with security attributes}
+
+\item {} \href{\#fdp-itc-1-import-of-user-data-without-security-attributes}{FDP{\_}ITC.1 Import of user data without security attributes}
+
+\item {} \href{\#fdp-itc-2-import-of-user-data-with-security-attributes}{FDP{\_}ITC.2 Import of user data with security attributes}
+
+\item {} \href{\#fdp-rip-1-subset-residual-information-protection}{FDP{\_}RIP.1 Subset residual information protection}
+
+\item {} \href{\#fdp-rol-2-transactions-advanced-rollback}{FDP{\_}ROL.2{\_}TRANSACTIONS Advanced Rollback}
+
+\item {} \href{\#fdp-rol-1-undo-basic-rollback}{FDP{\_}ROL.1{\_}UNDO Basic rollback}
+
+\end{list}
+
+\item {} \href{\#class-fia-identification-and-authentication}{Class FIA: Identification and authentication}
+\begin{list}{}{}
+\item {} \href{\#fia-afl-z-1-authentication-failure-handling}{FIA{\_}AFL{\_}z.1 Authentication failure handling}
+
+\item {} \href{\#fia-atd-1-user-attribute-definition}{FIA{\_}ATD.1 User attribute definition}
+
+\item {} \href{\#fia-uau-1-timing-of-authentication}{FIA{\_}UAU.1 Timing of authentication}
+
+\item {} \href{\#fia-uau-5-multiple-authentication-systems}{FIA{\_}UAU.5 Multiple authentication systems}
+
+\item {} \href{\#fia-uau-6-re-authentication}{FIA{\_}UAU.6 Re-authentication}
+
+\item {} \href{\#fia-usb-1-user-subject-binding}{FIA{\_}USB.1 User-subject binding}
+
+\end{list}
+
+\item {} \href{\#class-fmt-security-management}{Class FMT: Security management}
+\begin{list}{}{}
+\item {} \href{\#fmt-mof-1-management-of-security-functions}{FMT{\_}MOF.1 Management of security functions}
+
+\item {} \href{\#fmt-msa-1-management-of-security-attributes}{FMT{\_}MSA.1 Management of security attributes}
+
+\item {} \href{\#fmt-msa-3-static-attribute-initialisation}{FMT{\_}MSA.3 Static attribute initialisation}
+
+\item {} \href{\#fmt-smr-1-security-roles}{FMT{\_}SMR.1 Security roles}
+
+\end{list}
+
+\item {} \href{\#class-fpt-protection-of-the-tsf}{Class FPT: Protection of the TSF}
+\begin{list}{}{}
+\item {} \href{\#fpt-amt-1-abstract-machine-testing}{FPT{\_}AMT.1 Abstract machine testing}
+
+\item {} \href{\#fpt-fls-1-failure-with-preservation-of-secure-state}{FPT{\_}FLS.1 Failure with preservation of secure state}
+
+\item {} \href{\#fpt-rvm-1-non-bypassability-of-the-tsp}{FPT{\_}RVM.1 Non-bypassability of the TSP}
+
+\item {} \href{\#fpt-sep-1-tsf-domain-separation}{FPT{\_}SEP.1 TSF domain separation}
+
+\item {} \href{\#fpt-stm-1-reliable-time-stamps}{FPT{\_}STM.1 Reliable time stamps}
+
+\end{list}
+
+\end{list}
+
+\end{list}
+
+\item {} \href{\#toe-security-assurance-requirements}{TOE security assurance requirements}
+
+\item {} \href{\#security-requirements-for-the-it-environment}{Security requirements for the IT environment}
+
+\item {} \href{\#security-requirements-for-the-non-it-environment}{Security requirements for the non-IT environment}
+
+\end{list}
+
+\item {} \href{\#toe-summary-specification}{TOE summary specification}
+\begin{list}{}{}
+\item {} \href{\#toe-security-functions}{TOE security functions}
+
+\item {} \href{\#protection}{Protection}
+
+\item {} \href{\#authentication}{Authentication}
+
+\item {} \href{\#authorization-access-control}{Authorization / Access Control}
+
+\item {} \href{\#auditing}{Auditing}
+
+\item {} \href{\#transaction-management}{Transaction management}
+
+\item {} \href{\#undo}{Undo}
+
+\item {} \href{\#publication-server}{Publication / Server}
+
+\item {} \href{\#automated-tests}{Automated Tests}
+
+\item {} \href{\#python-environment-xxx}{Python Environment XXX}
+
+\item {} \href{\#table-functions-to-security-functional-requirements-mapping}{Table: Functions to Security Functional Requirements Mapping}
+
+\item {} \href{\#table-security-functional-requirements-to-functions-mapping}{Table: Security Functional Requirements to Functions Mapping}
+
+\item {} \href{\#assurance-measures}{Assurance measures}
+\begin{list}{}{}
+\item {} \href{\#am-acm-configuration-management}{AM{\_}ACM: CONFIGURATION MANAGEMENT}
+
+\item {} \href{\#am-ado-delivery-and-operation}{AM{\_}ADO: DELIVERY AND OPERATION}
+
+\item {} \href{\#am-adv-development}{AM{\_}ADV: DEVELOPMENT}
+
+\item {} \href{\#am-agd-guidance-documents}{AM{\_}AGD: GUIDANCE DOCUMENTS}
+
+\item {} \href{\#am-ate-tests}{AM{\_}ATE: TESTS}
+
+\end{list}
+
+\end{list}
+
+\item {} \href{\#pp-claims}{PP claims}
+
+\item {} \href{\#sof-claims}{SOF claims}
+
+\item {} \href{\#rationale}{Rationale}
+\begin{list}{}{}
+\item {} \href{\#security-objectives-rationale}{Security objectives rationale}
+\begin{list}{}{}
+\item {} \href{\#table-mapping-of-threats-to-security-objectives}{Table: Mapping of Threats to Security Objectives}
+
+\end{list}
+
+\item {} \href{\#security-requirements-rationale}{Security requirements rationale}
+\begin{list}{}{}
+\item {} \href{\#choice-of-security-functional-requirements}{Choice of security functional requirements}
+
+\end{list}
+
+\item {} \href{\#justification-for-suitability-of-sfr-toe-security-objectives}{Justification for suitability of SFR - TOE security objectives}
+\begin{list}{}{}
+\item {} \href{\#choice-of-toe-security-assurance-requirements}{Choice of TOE security assurance requirements}
+
+\end{list}
+
+\item {} \href{\#evaluation-assurance-level-rationale}{Evaluation Assurance Level rationale:}
+
+\end{list}
+
+\item {} \href{\#glossary}{Glossary}
+
+\item {} \href{\#todo}{TODO}
+\begin{list}{}{}
+\item {} \href{\#general}{General}
+
+\item {} \href{\#part-1}{Part 1}
+
+\item {} \href{\#part-2}{Part 2}
+
+\end{list}
+
+\end{list}
+
+
+
+%___________________________________________________________________________
+
+\hypertarget{document-history}{}
+\pdfbookmark[0]{Document History}{document-history}
+\section*{Document History}
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.11\locallinewidth}|p{0.11\locallinewidth}|p{0.23\locallinewidth}|p{0.20\locallinewidth}|}
+\hline
+\textbf{
+Version
+} & \textbf{
+Date
+} & \textbf{
+Change
+} & \textbf{
+Editor
+} \\
+\hline
+\endhead
+
+0.1
+ & &
+First draft
+ &
+Christian Theune
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{st-introduction}{}
+\pdfbookmark[0]{ST introduction}{st-introduction}
+\section*{ST introduction}
+
+
+%___________________________________________________________________________
+
+\hypertarget{st-identification}{}
+\pdfbookmark[1]{ST identification}{st-identification}
+\subsection*{ST identification}
+\begin{quote}
+\begin{description}
+\item [Document Title:]
+Zope X3, Security target
+
+
+\item [Document ID:]
+{\$}Id: SecurityTarget.txt 30023 2005-04-18 13:47:51Z zagy {\$}
+
+
+\item [Document Version:]
+{\$}Rev: 30023 {\$}
+
+
+\item [Origin:]
+Zope Corporation public CVS server
+
+
+\item [TOE Reference:]
+Zope X3 3.1/CC
+
+
+\item [TOE Commercial Name:]
+Zope X3
+
+
+\item [TOE Short Description:]
+A platform independent web application server and framework written in Python
+
+
+\item [Product Type:]
+Web Application Server
+
+
+\item [Evaluation Body:]
+Evaluation Body of TUV Informationstechnik GmbH, Germany
+
+
+\item [Certification Body:]
+Certification Body of TUV Informationstechnik GmbH, Germany
+
+
+\end{description}
+\end{quote}
+
+This ST is based upon Common Criteria, Version 2.1 (\emph{{[}CC]}).
+The TOE consists of the following component:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.14\locallinewidth}|p{0.13\locallinewidth}|p{0.20\locallinewidth}|}
+\hline
+\textbf{
+Component
+} & \textbf{
+Version
+} & \textbf{
+Supplier
+} \\
+\hline
+\endhead
+
+Zope
+ &
+X3
+ &
+Zope Corporation
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{st-overview}{}
+\pdfbookmark[1]{ST overview}{st-overview}
+\subsection*{ST overview}
+
+The main objectives of this Security Target are:
+\begin{quote}
+\begin{itemize}
+\item {}
+To describe the Target of Evaluation (TOE).
+
+\item {}
+To describe the security environment of the TOE including the assets to
+be protected and the threats to be countered by the TOE and its
+environment.
+
+\item {}
+To describe the security objectives of the TOE and its supporting
+environment.
+
+\item {}
+To specify the Security Requirements, which include the TOE security
+functional requirements as of CC, part 2 and the assurance requirements as
+of CC, part 3.
+
+\item {}
+To set up the TOE summary specification, which includes the TOE
+security functions specifications and the assurance measures.
+
+\end{itemize}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{iso-iec-15408-cc-conformance}{}
+\pdfbookmark[1]{ISO/IEC 15408 (CC) Conformance}{iso-iec-15408-cc-conformance}
+\subsection*{ISO/IEC 15408 (CC) Conformance}
+
+This ST is claimed to be conformant with the ISO/IEC 15408:1999 (Common
+Criteria, Version 2.1 with final interpretations, see \emph{{[}CC]}) and its following
+parts:
+\begin{quote}
+\begin{itemize}
+\item {}
+Part 2 and
+
+\item {}
+Part 3, EAL1.
+
+\end{itemize}
+\end{quote}
+
+The assurance level is EAL 1.
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-description}{}
+\pdfbookmark[0]{TOE description}{toe-description}
+\section*{TOE description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{overview}{}
+\pdfbookmark[1]{Overview}{overview}
+\subsection*{Overview}
+
+Zope 3 (also referred to as ``Zope'') is a component based framework that may be
+used to build web applications. It's development is historically focused but
+not limited on building content management systems.
+
+It is written as platform independent software using the Python programming
+language. Therefore it is available for Windows NT, Linux, MacOS X and other
+operating systems.
+
+Zope 3 features a set of core components that form an infrastructure for
+building applications by reusing existing components and adding new components
+that work together by defined interfaces.
+
+The core functionality contains a web server with WebDAV support, a ftp server
+and a XML/RPC server. It has components that provide functionality for
+security management including administration of users, roles and permissions.
+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, I18n and L10n support and many more.
+
+Finally Zope can be extended by the use of packages that can contain
+configuration directives, templates, Python code and classes. Those are
+intended to work together seamlessly using the Component Architecture to plug
+them together into more complex systems.
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-definition}{}
+\pdfbookmark[1]{TOE definition}{toe-definition}
+\subsection*{TOE definition}
+
+As a general rule it is possible to describe all activities with and within Zope as
+``operations'' performed on ``objects''. The need for security adds a protecting
+subject to this by guarding operations with ``permissions''.
+
+Users of the system are internally identified with ``principals'' which act on
+their behalf. Those principals are granted permissions (both statically via
+configuration files and dynamically via settings in the object database) within
+an context to allow them performing operations on a selected set of objects.
+
+Principals are authenticated in various ways depending on the means of
+connection to a server. Authentication usually envolves a username-password
+pair such as for FTP-Authentication and HTTP-Basic-Authentication. Other
+authentication mechanisms are possible.
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-development-and-production}{}
+\pdfbookmark[1]{TOE Development and Production}{toe-development-and-production}
+\subsection*{TOE Development and Production}
+
+The development of Zope 3 is driven by the Zope Corporation together with the
+free community of Zope developers. The Zope 3 source code is free to be
+retrieved and used by everybody.
+
+The official Zope 3 source code is maintained within a centralized source-code
+control system. Everybody is free to retrieve any available version of the
+code anonymously. The certified version is available on a named branch and
+identified by a tag.
+
+To ensure a stable production every developer wishing to directly access the
+repository must retrieve authorisation from Zope Corporation. This is
+expressed by providing a signed contributors agreement,
+\href{http://dev.zope.org/DevHome/Subversion/Contributor.pdf}{http://dev.zope.org/DevHome/Subversion/Contributor.pdf}.
+
+Write access to the repository is only available through ssh and by providing
+a public key to the maintainer of the repository.
+
+All changes to source code and other files in the repository are reported
+publically to interested persons including those persons that are responsible
+for overseeing the quality and direction of parts of Zope.
+
+Any change to a file in the repository causes that file to have a new version
+number and the exact change is recorded. Before writing a change back to the
+repository on a branch that is declared for public use or for main development
+(release branches, HEAD, main development branches) the developer must
+successfully run the prepared unit tests to assure that no code breaks when
+applying his changes. Additionally every developer is required to provide unit
+test for new code he writes or problems he solves, as far as applicable.
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-life-cycle}{}
+\pdfbookmark[1]{TOE Life Cycle}{toe-life-cycle}
+\subsection*{TOE Life Cycle}
+
+The TOE is developed in cycles. New features are introduced in iterative steps
+called ``feature release'' and solutions to known problems are introduced by
+steps called ``bugfix releases''.
+
+The version numbers of the TOE releases express if it is a feature or bugfix
+release like this: 3.f.b where f and b are continuous given numbers and f
+expresses the f-th feature relase for Zope 3 and b expresses the b-th bugfix
+relase for the f-th feature release. Every feature release starts with bugfix
+release 0 in which case the bugfix number may be ommitted. (E.g. 3.1.4,
+3.1.0/3.1, 3.0.0/3.0)
+
+Test releases are identified by adding their grade (a for alpha, b for beta, rc
+for release candidate) at the end of the version number that it is targeted at.
+(3.1.4b2 would be the second beta release for the upcoming version 3.1.4)
+
+New features are proposed and agreed within the developers community by the use
+of mailinglists and wiki pages. They are incorportated in an agreed feature
+release.
+
+Until agreed to be ready for public test the development and until all
+features are available (but maybe untested), development of a feature release
+happens on the SVN trunk (a special branch, also known as HEAD). When starting
+public releases, no further features are allowed to be introduced and the
+development enters maintenance mode. Therefore a named branch is created to
+identify changes that are applied for maintenance. New features will be
+introduced on the trunk that is heading for the next feature release.
+
+Therefore an overall of about 3 concurrent maintained versions can exist:
+\begin{quote}
+\begin{itemize}
+\item {}
+old feature release in maintenance mode
+
+\item {}
+upcoming feature release, already in maintance mode but not stable
+
+\item {}
+upcoming feature relaese in free development mode
+
+\end{itemize}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-boundaries}{}
+\pdfbookmark[1]{TOE Boundaries}{toe-boundaries}
+\subsection*{TOE Boundaries}
+
+
+%___________________________________________________________________________
+
+\hypertarget{physical-boundaries}{}
+\pdfbookmark[2]{Physical Boundaries}{physical-boundaries}
+\subsubsection*{Physical Boundaries}
+
+The TOE is physically limited by the files that are included in a Zope 3
+source software distribution. A binary distribution may include more software
+packages that are not part of the TOE. (E.g. Python runtime libraries)
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-logical-boundaries}{}
+\pdfbookmark[2]{TOE Logical Boundaries}{toe-logical-boundaries}
+\subsubsection*{TOE Logical Boundaries}
+
+The logical boundary for the TOE consists of the four security sub-systems of
+Zope:
+\begin{itemize}
+\item {}
+permission declaration
+
+\item {}
+protection
+
+\item {}
+authentication
+
+\item {}
+authorization
+
+\end{itemize}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-security-environment}{}
+\pdfbookmark[0]{TOE security environment}{toe-security-environment}
+\section*{TOE security environment}
+
+
+%___________________________________________________________________________
+
+\hypertarget{assets}{}
+\pdfbookmark[1]{Assets}{assets}
+\subsection*{Assets}
+
+The following primary assets have been identified:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.21\locallinewidth}|p{0.62\locallinewidth}|}
+\hline
+\textbf{
+Asset Name
+} & \textbf{
+Description
+} \\
+\hline
+\endhead
+
+(Content) Objects
+ &
+Generic objects (instances of Python classes) that
+are stored and controlled by Zope and carry
+information that is to be protected. Objects are
+stored in a connected manner that is typically
+hierarchical and allows the derivation of
+information by the objects context.
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+The following secondary assets have been identified:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.21\locallinewidth}|p{0.67\locallinewidth}|}
+\hline
+\textbf{
+Asset Name
+} & \textbf{
+Description
+} \\
+\hline
+\endhead
+
+Host System
+ &
+The unit of computer hardware and software that
+forms the environment of Zope to run on. (E.g.
+a PC server with Windows 2000 or Linux installed)
+ \\
+\hline
+
+Operations
+ &
+Operations are the way of accessing and modifying
+data provided by (content) objects.
+ \\
+\hline
+
+Principals
+ &
+Principals are the systems representation of acting
+individuals. A principal acts in behalf of the user
+and represents a (content) object of it's own.
+ \\
+\hline
+
+Permission
+ &
+A permission is a name guarding an operation.
+ \\
+\hline
+
+Permission grants
+ &
+A permission grant associates a principal with a
+permission to allow or deny an operation in the context.
+As a third state, permissions may be declared to
+be acquired from the context.
+ \\
+\hline
+
+Audit data
+ &
+The data generated by the TOE audit subsystem.
+ \\
+\hline
+
+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.
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{subject}{}
+\pdfbookmark[1]{Subject}{subject}
+\subsection*{Subject}
+
+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
+server request (for example, Web requests). Interactions are referred
+to as ``subjects'' in the TOE.
+
+
+%___________________________________________________________________________
+
+\hypertarget{operations}{}
+\pdfbookmark[1]{Operations}{operations}
+\subsection*{Operations}
+
+Operations are performed on objects. They are defined in an objects 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, a
+method or some other related python thing.
+
+There are two possible kinds of access to an operation: Reading such as
+reading an attribute or calling a method. Writing such as setting or deleting
+an attribute. Reading and writing can be guarded with different permission grants.
+
+
+%___________________________________________________________________________
+
+\hypertarget{assumptions-about-the-environment}{}
+\pdfbookmark[1]{Assumptions (about the environment)}{assumptions-about-the-environment}
+\subsection*{Assumptions (about the environment)}
+
+The following assumptions need to be made about the TOE environment:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.19\locallinewidth}|p{0.61\locallinewidth}|}
+\hline
+\textbf{
+Assumption Name
+} & \textbf{
+Description
+} \\
+\hline
+\endhead
+
+A.OS
+ &
+The machine and the operating system Zope is
+running on is physically secure.
+ \\
+\hline
+
+A.Admin
+ &
+The ``system-administrator'' of the above
+mentioned machine is trustworthy.
+ \\
+\hline
+
+A.Network
+ &
+A network connection to the Zope services is
+present. All other network connection are
+secure in such a way that the integrity of
+the machine and operating system is preserved.
+ \\
+\hline
+
+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.
+ \\
+\hline
+
+A.Credential
+ &
+The user is keeping the credential to authenticate
+secret.
+ \\
+\hline
+
+A.Integrity
+ &
+The system is administrated such that the system is
+free from malicious software like viruses and
+Trojan horses.
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{threats}{}
+\pdfbookmark[1]{Threats}{threats}
+\subsection*{Threats}
+
+The following threat agents have been identified:
+\begin{quote}
+\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}
+\end{quote}
+
+The following threats against the assets have been identified:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.11\locallinewidth}|p{0.35\locallinewidth}|p{0.49\locallinewidth}|}
+\hline
+\textbf{
+Threat
+} & \textbf{
+Threat description
+} & \textbf{
+Asset
+} \\
+\hline
+\endhead
+
+T.IA
+ &
+An attacker might impersonate an authorized
+principal without providing the necessary
+credentials.
+ &
+Principal
+ \\
+\hline
+
+T.Perm
+ &
+A principal changes the permission grants
+without having the right to do so.
+ &
+Permission grants,
+ \\
+\hline
+
+T.Operation
+ &
+A principal performs an operation on an object
+without having the correct permission.
+ &
+Operation, Object
+ \\
+\hline
+
+T.AuditFake
+ &
+An attacker might convince the audit data
+generation functions to log false information
+(date, time, type of event, outcome, user)
+ &
+Audit data
+ \\
+\hline
+
+T.Import
+ &
+An attacker might try to make the system
+interpret imported security attributes in a
+not intended way to acquire a higher level of
+access to the system.
+ &
+Secondary assets
+ \\
+\hline
+
+T.RIP
+ &
+An attacker might try to make the system use
+residual information for deciding to allow
+or deny access to an operation to gain more
+access than intended.
+ &
+Secondary assets
+ \\
+\hline
+
+T.Transaction
+ &
+An attacker might try to perform commit or
+abort operations on foreign transactions to
+perform operations on the behalf of other
+users.
+ &
+XXX was given by TUV. not sure if this really applies ...
+All assets in ZODB
+ \\
+\hline
+
+T.Undo
+ &
+An attacker might try to perform an Undo
+operation to invalid revisions.
+ &
+All assets in ZODB
+ \\
+\hline
+
+T.USB
+ &
+An attacker might try to use executable code
+which runs on behalf of another user to perform
+unauthorized operations and maybe hide his
+traces.
+ &
+XXX does this only apply to TTW code which we dropped anyway?
+ \\
+\hline
+
+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
+ \\
+\hline
+
+T.TrustedPath
+ &
+An attacker might try to use ``user data import''
+or ``user data export'' without being a local
+user and using the trusted path.
+ &
+Object
+ \\
+\hline
+
+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
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{organisational-security-policies}{}
+\pdfbookmark[1]{Organisational security policies}{organisational-security-policies}
+\subsection*{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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-objectives}{}
+\pdfbookmark[0]{Security objectives}{security-objectives}
+\section*{Security objectives}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-objectives-for-the-toe}{}
+\pdfbookmark[1]{Security objectives for the TOE}{security-objectives-for-the-toe}
+\subsection*{Security objectives for the TOE}
+
+The following security objectives have been defined for the TOE:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.17\locallinewidth}|p{0.77\locallinewidth}|}
+\hline
+\textbf{
+Objective Name
+} & \textbf{
+Description
+} \\
+\hline
+\endhead
+
+O.IA
+ &
+All principals must be accurately identified and
+authenticated with the exception of the ``unauthenticated''
+principal.
+ \\
+\hline
+
+O.Delegation
+ &
+Provide the ability to securely delegate control. Users can
+delegate the ability to control access to selected
+operations to others. To delegate a permission, a meta permission
+that allows you to delegate this permission must be granted.
+ \\
+\hline
+
+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.
+ \\
+\hline
+
+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.
+ \\
+\hline
+
+O.Access
+ &
+The TOE ensures that access to objects is always
+mediated by operations and guarded by permissions.
+ \\
+\hline
+
+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.
+ \\
+\hline
+
+O.Attributes
+ &
+Whenever attributes are set using identifiers
+(e.g. principal or permission identifiers), the
+identifiers must have been defined previously.
+ \\
+\hline
+
+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.
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-objectives-for-the-environment}{}
+\pdfbookmark[1]{Security objectives for the environment}{security-objectives-for-the-environment}
+\subsection*{Security objectives for the environment}
+
+The following security objectives have been defined for the TOE environment:
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.19\locallinewidth}|p{0.66\locallinewidth}|}
+\hline
+\textbf{
+Assumption Name
+} & \textbf{
+Description
+} \\
+\hline
+\endhead
+
+OE.OS
+ &
+The machine and the operating system Zope is running
+on is physically secure.
+ \\
+\hline
+
+OE.Trust
+ &
+Those responsible for the TOE must be trustworthy.
+ \\
+\hline
+
+OE.Manage
+ &
+Those responsible for the TOE must ensure that the TOE
+is delivered, installed, managed, and operated in a
+manner which maintains IT security.
+ \\
+\hline
+
+OE.AUDITLOG
+ &
+Administrators of the TOE must ensure that audit
+facilities are used and managed effectively. In
+particular:
+\newcounter{listcnt1}
+\begin{list}{\alph{listcnt1})}
+{
+\usecounter{listcnt1}
+\setlength{\rightmargin}{\leftmargin}
+}
+\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{list}
+ \\
+\hline
+
+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.
+ \\
+\hline
+
+OE.Client
+ &
+The connection between client and Zope server is secure
+in a sense that the identification and authentication
+data is not monitored or interfered.
+ \\
+\hline
+
+OE.Credential
+ &
+The user is keeping the credentials to authenticate
+secret.
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-requirements}{}
+\pdfbookmark[0]{Security requirements}{security-requirements}
+\section*{Security requirements}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-security-requirements}{}
+\pdfbookmark[1]{TOE security requirements}{toe-security-requirements}
+\subsection*{TOE security requirements}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-security-functional-requirements}{}
+\pdfbookmark[2]{TOE security functional requirements}{toe-security-functional-requirements}
+\subsubsection*{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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{class-fau-audit-data-generation}{}
+\pdfbookmark[3]{Class FAU: Audit data generation}{class-fau-audit-data-generation}
+\subsubsection*{Class FAU: Audit data generation}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fau-gen-1-audit-data-generation}{}
+\pdfbookmark[4]{FAU{\_}GEN.1 Audit data generation}{fau-gen-1-audit-data-generation}
+\subsubsection*{FAU{\_}GEN.1 Audit data generation}
+\begin{description}
+%[visit_definition_list_item]
+\item[FAU{\_}GEN.1.1]
+%[visit_definition]
+
+The TSF shall be able to generate an audit record of the following auditable
+events:
+\newcounter{listcnt2}
+\begin{list}{\alph{listcnt2})}
+{
+\usecounter{listcnt2}
+\setlength{\rightmargin}{\leftmargin}
+}
+\item {}
+Startup and shutdown of audit functions;
+
+\item {}
+All auditable events for the \emph{{[}minimum]} level of audit; and
+
+\item {}
+\emph{{[}select: other events XXX]}
+
+\end{list}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FAU{\_}GEN.1.2]
+%[visit_definition]
+
+The TSF shall record within each audit record at least the
+following information:
+\newcounter{listcnt3}
+\begin{list}{\alph{listcnt3})}
+{
+\usecounter{listcnt3}
+\setlength{\rightmargin}{\leftmargin}
+}
+\item {}
+Date and time of the event, type of event, subject identity,
+and the outcome (success or failure) of the event; and
+
+\item {} \begin{description}
+%[visit_definition_list_item]
+\item[For each audit event type, based on auditable event definitions]
+%[visit_definition]
+
+of the functional components included in the ST,
+\emph{{[}assignment: the ID of the corresponding interaction]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+\end{list}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fau-gen-2-user-identity-assocation}{}
+\pdfbookmark[4]{FAU{\_}GEN.2 User identity assocation}{fau-gen-2-user-identity-assocation}
+\subsubsection*{FAU{\_}GEN.2 User identity assocation}
+\begin{description}
+%[visit_definition_list_item]
+\item[FAU{\_}GEN.2.1]
+%[visit_definition]
+
+The TSF shall be able to associate each auditable event with the identity
+of the user that caused the event.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{class-fdp-data-protection}{}
+\pdfbookmark[3]{Class FDP: Data protection}{class-fdp-data-protection}
+\subsubsection*{Class FDP: Data protection}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-acc-2-complete-access-control}{}
+\pdfbookmark[4]{FDP{\_}ACC.2 Complete access control}{fdp-acc-2-complete-access-control}
+\subsubsection*{FDP{\_}ACC.2 Complete access control}
+\begin{description}
+%[visit_definition_list_item]
+\item[FDP{\_}ACC.2.1 ]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} on
+\emph{{[}subjects: interactions and objects: content objects]} and all
+operations among subjects and objects covered by the SFP.
+\begin{description}
+%[visit_definition_list_item]
+\item[XXX]
+%[visit_definition]
+
+We now protect adapters of various kinds. This implies that
+adapters are assets, but we think that they should not be.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ACC.2.2]
+%[visit_definition]
+
+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.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-acf-1-security-attribute-based-access-control}{}
+\pdfbookmark[4]{FDP{\_}ACF.1 Security attribute based access control}{fdp-acf-1-security-attribute-based-access-control}
+\subsubsection*{FDP{\_}ACF.1 Security attribute based access control}
+\begin{description}
+%[visit_definition_list_item]
+\item[FDP{\_}ACF.1.1]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to objects
+based on \emph{{[}the interaction principal, the permission required for
+the operation and the grants or denials of the permission for that
+object or it's ancestor objects]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ACF.1.2]
+%[visit_definition]
+
+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 denied if there is a denial for the subject's
+principal for the required permission on the object.
+
+\item {}
+Access is allowed if there is a grant and there is not a denial
+for the subject's principal for the required permission on the object.
+
+\item {}
+Access is denied if access would be denied for the subject's
+principal for the required permission on the parent of the
+object.
+
+\item {}
+Access is allowed if access would be allowed and would not be
+denied for the subject's principal for the required permission
+on the parent of the object.
+
+\end{itemize}
+
+where the required permission is the permission required to
+perform the desired operation on the object.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ACF.1.3]
+%[visit_definition]
+
+The TSF shall explicitly authorise access of subjects to
+objects based on the following additional rules: \emph{{[}none]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ACF.1.4]
+%[visit_definition]
+
+The TSF shall explicitly deny access of subjects to objects
+based on the following additional rules: \emph{{[}none]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-etc-2-export-of-user-data-with-security-attributes}{}
+\pdfbookmark[4]{FDP{\_}ETC.2 Export of user data with security attributes}{fdp-etc-2-export-of-user-data-with-security-attributes}
+\subsubsection*{FDP{\_}ETC.2 Export of user data with security attributes}
+\begin{description}
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+The TOE may, initially, satisfy the requirements in this
+function by not supporting data export, or, by only
+supporting export from outside the TSC (outside the
+software interfaces).
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ETC.2.1]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} when exporting user
+data, controlled under the SFP, outside the TSC.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ETC.2.2]
+%[visit_definition]
+
+The TSF shall export the user data with the user data's associated
+security attributes.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ETC.2.3]
+%[visit_definition]
+
+The TSF shall ensure that the security attributes, when
+exported outside the TSC, are unambiguously associated
+with the exported user data.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ETC.2.4]
+%[visit_definition]
+
+The TSF shall enforce the following rules when user data
+is exported from the TSC: \emph{{[}none]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-itc-1-import-of-user-data-without-security-attributes}{}
+\pdfbookmark[4]{FDP{\_}ITC.1 Import of user data without security attributes}{fdp-itc-1-import-of-user-data-without-security-attributes}
+\subsubsection*{FDP{\_}ITC.1 Import of user data without security attributes}
+\begin{description}
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+The TOE may, initially, satisfy the requirements in this
+function by not supporting data import, or, by only
+supporting import from outside the TSC (outside the
+software interfaces).
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.1.1]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} when importing user
+data, controlled under the SFP, from outside of the TSC.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.1.2]
+%[visit_definition]
+
+The TSF shall ignore any security attributes associated with the user data
+when imported from outside the TSC.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.1.3]
+%[visit_definition]
+
+The TSF shall enforce the following rules when importing user data
+controlled under the SFP from outside the TSC:
+\begin{quote}
+
+No security attributes will be set when importing. The imported
+user data will have no security attributes.
+\begin{description}
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+Access to the imported data will be governed by the grants in
+the location the data are imported into, as described in
+FDP{\_}ACF.1.2.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+\end{quote}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-itc-2-import-of-user-data-with-security-attributes}{}
+\pdfbookmark[4]{FDP{\_}ITC.2 Import of user data with security attributes}{fdp-itc-2-import-of-user-data-with-security-attributes}
+\subsubsection*{FDP{\_}ITC.2 Import of user data with security attributes}
+\begin{description}
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+The TOE may, initially, satisfy the requirements in this
+function by not supporting data import, or, by only
+supporting import from outside the TSC (outside the
+software interfaces).
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.2.1]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} when importing user
+data, controlled under the SFP, from outside of the TSC.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.2.2 ]
+%[visit_definition]
+
+The TSF shall use the security attributes associated with the imported
+user data.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.2.3]
+%[visit_definition]
+
+The TSF shall ensure that the protocol used provides for the unambiguous
+association between the security attributes and the user data received.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.2.4]
+%[visit_definition]
+
+The TSF shall ensure that interpretation of the security attributes of
+the imported user data is as intended by the source of the user data.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ITC.2.5]
+%[visit_definition]
+
+The TSF shall enforce the following rules when importing user data
+controlled under the SFP from outside the TSC:
+\begin{itemize}
+\item {}
+If any imported data has security attributes that refer to
+permissions or principals not defined in the target system, the
+entire import will fail and an explanatory error will be provided.
+
+\end{itemize}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-rip-1-subset-residual-information-protection}{}
+\pdfbookmark[4]{FDP{\_}RIP.1 Subset residual information protection}{fdp-rip-1-subset-residual-information-protection}
+\subsubsection*{FDP{\_}RIP.1 Subset residual information protection}
+\begin{description}
+%[visit_definition_list_item]
+\item[FDP{\_}RIP.2.1]
+%[visit_definition]
+
+The TSF shall ensure that any previous information content of a
+resource is made unavailable upon the \emph{{[}selection: deallocation of
+the resource from]} all objects.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[XXX ]
+%[visit_definition]
+
+need to think through the implications of undo for rip -- Steve's
+``Bob'' example.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-rol-2-transactions-advanced-rollback}{}
+\pdfbookmark[4]{FDP{\_}ROL.2{\_}TRANSACTIONS Advanced Rollback}{fdp-rol-2-transactions-advanced-rollback}
+\subsubsection*{FDP{\_}ROL.2{\_}TRANSACTIONS Advanced Rollback}
+\begin{description}
+%[visit_definition_list_item]
+\item[FDP{\_}ROL.2.1 ]
+%[visit_definition]
+
+The TSF shall permit \emph{{[}the rollback of all
+operations on all objects]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ROL.2.2 ]
+%[visit_definition]
+
+The TSF shall permit operations to be rolled
+back \emph{{[}at any time before the transaction in which the operation was
+performed is committed]}.
+\begin{description}
+%[visit_definition_list_item]
+\item[Note ]
+%[visit_definition]
+
+This statement may not apply to cached data created
+during the course of a transaction.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fdp-rol-1-undo-basic-rollback}{}
+\pdfbookmark[4]{FDP{\_}ROL.1{\_}UNDO Basic rollback}{fdp-rol-1-undo-basic-rollback}
+\subsubsection*{FDP{\_}ROL.1{\_}UNDO Basic rollback}
+\begin{description}
+%[visit_definition_list_item]
+\item[FDP{\_}ROL.1.1 ]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to permit
+the rollback of the \emph{{[}operations that caused changes]} on the \emph{{[}content
+objects]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FDP{\_}ROL.1.2 ]
+%[visit_definition]
+
+The TSF shall permit operations to be rolled back
+within the \emph{{[}period of time for which the old revisions of the objects
+exist]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{class-fia-identification-and-authentication}{}
+\pdfbookmark[3]{Class FIA: Identification and authentication}{class-fia-identification-and-authentication}
+\subsubsection*{Class FIA: Identification and authentication}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-afl-z-1-authentication-failure-handling}{}
+\pdfbookmark[4]{FIA{\_}AFL{\_}z.1 Authentication failure handling}{fia-afl-z-1-authentication-failure-handling}
+\subsubsection*{FIA{\_}AFL{\_}z.1 Authentication failure handling}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}AFL{\_}z.1.1]
+%[visit_definition]
+
+The TSF shall detect when there are configurable number of consecutive
+unsuccessful authentication attempts for a single login name,
+with no intermediate successful attempts.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FIA{\_}AFL{\_}z.1.2 ]
+%[visit_definition]
+
+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}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-atd-1-user-attribute-definition}{}
+\pdfbookmark[4]{FIA{\_}ATD.1 User attribute definition}{fia-atd-1-user-attribute-definition}
+\subsubsection*{FIA{\_}ATD.1 User attribute definition}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}ATD.1.1 ]
+%[visit_definition]
+
+The TSF shall maintain the following list of security attributes
+belonging to individual principals \emph{{[}uniqueid, credentials, grants
+and denials]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-uau-1-timing-of-authentication}{}
+\pdfbookmark[4]{FIA{\_}UAU.1 Timing of authentication}{fia-uau-1-timing-of-authentication}
+\subsubsection*{FIA{\_}UAU.1 Timing of authentication}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}UAU.1.1 ]
+%[visit_definition]
+
+The TSF shall allow \emph{{[}only those operations granted to the
+unauthenticated principal]} on behalf of the user before the user is
+authenticated.
+
+\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. This fullfills the terms of FIA{\_}UAU.2]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FIA{\_}UAU.1.2 ]
+%[visit_definition]
+
+The TSF shall require each \emph{{[}user]} to be successfully
+authenticated before allowing any other TSF-mediated actions on behalf
+of that user.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-uau-5-multiple-authentication-systems}{}
+\pdfbookmark[4]{FIA{\_}UAU.5 Multiple authentication systems}{fia-uau-5-multiple-authentication-systems}
+\subsubsection*{FIA{\_}UAU.5 Multiple authentication systems}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}UAU.5.1 ]
+%[visit_definition]
+
+The TSF shall provide \emph{{[}extensible support for multiple
+authentication mechanisms. The default mechanism uses login names
+and passwords in combination with HTTP Basic Authentication and FTP
+authentication]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FIA{\_}UAU.5.2]
+%[visit_definition]
+
+The TSF shall authenticate any users claimed identity according to
+the \emph{{[}system configuration, provided credentials, such as a
+username/password pair and the protocol used]}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-uau-6-re-authentication}{}
+\pdfbookmark[4]{FIA{\_}UAU.6 Re-authentication}{fia-uau-6-re-authentication}
+\subsubsection*{FIA{\_}UAU.6 Re-authentication}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}UAU.6.1 ]
+%[visit_definition]
+
+The TSF shall 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}
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fia-usb-1-user-subject-binding}{}
+\pdfbookmark[4]{FIA{\_}USB.1 User-subject binding}{fia-usb-1-user-subject-binding}
+\subsubsection*{FIA{\_}USB.1 User-subject binding}
+\begin{description}
+%[visit_definition_list_item]
+\item[FIA{\_}USB.1.1]
+%[visit_definition]
+
+The TSF shall associate the appropriate user security
+attributes with subjects acting on behalf of that user.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{class-fmt-security-management}{}
+\pdfbookmark[3]{Class FMT: Security management}{class-fmt-security-management}
+\subsubsection*{Class FMT: Security management}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fmt-mof-1-management-of-security-functions}{}
+\pdfbookmark[4]{FMT{\_}MOF.1 Management of security functions}{fmt-mof-1-management-of-security-functions}
+\subsubsection*{FMT{\_}MOF.1 Management of security functions}
+\begin{description}
+%[visit_definition_list_item]
+\item[FMT{\_}MOF.1.1]
+%[visit_definition]
+
+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{{[}assignment:
+authorized administrators]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+This includes for example adding and removing principals (for example,
+users) and changing the authentication schemes. Those actions can be
+protected by different permissions.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fmt-msa-1-management-of-security-attributes}{}
+\pdfbookmark[4]{FMT{\_}MSA.1 Management of security attributes}{fmt-msa-1-management-of-security-attributes}
+\subsubsection*{FMT{\_}MSA.1 Management of security attributes}
+\begin{description}
+%[visit_definition_list_item]
+\item[FMT{\_}MSA.1.1.grants]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to restrict
+the ability to \emph{{[}query, modify, delete,
+and add]]} the security attributes \emph{{[}permission grants and denials]} to
+\emph{{[}authorized grantors]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FMT{\_}MSA.1.1.loginname]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to restrict
+the ability to \emph{{[}query and modify]} the security
+attribute \emph{{[}login name]} to \emph{{[}authorized administrators and users
+authorized to modify their own authentication data]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FMT{\_}MSA.1.1.password]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to restrict
+the ability to \emph{{[}modify]} the security attribute
+\emph{{[}password]} to \emph{{[}authorized administrators and users authorized to
+modify their own authentication data]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fmt-msa-3-static-attribute-initialisation}{}
+\pdfbookmark[4]{FMT{\_}MSA.3 Static attribute initialisation}{fmt-msa-3-static-attribute-initialisation}
+\subsubsection*{FMT{\_}MSA.3 Static attribute initialisation}
+\begin{description}
+%[visit_definition_list_item]
+\item[FMT{\_}MSA.3.1]
+%[visit_definition]
+
+The TSF shall enforce the \emph{{[}formal security policy]} to provide
+\emph{{[}restrictive]} default values for security attributes that are used to
+enforce the SFP.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FMT{\_}MSA.3.2 ]
+%[visit_definition]
+
+The TSF shall allow \emph{{[}no one]} to specify alternative
+initial values to override the default values when an object or
+information is created.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[Note]
+%[visit_definition]
+
+Security attributes are expressed as collections of grants or
+denials. The default is an empty collection.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fmt-smr-1-security-roles}{}
+\pdfbookmark[4]{FMT{\_}SMR.1 Security roles}{fmt-smr-1-security-roles}
+\subsubsection*{FMT{\_}SMR.1 Security roles}
+
+XXX update/rewrite section
+\begin{description}
+%[visit_definition_list_item]
+\item[FMT{\_}SMR.1.1]
+%[visit_definition]
+
+The TSF shall maintain the roles:
+\begin{description}
+%[visit_definition_list_item]
+\item[Authorized administrator]
+%[visit_definition]
+
+Users who can perform system-wide security functions. These are
+people who have the zope.ManageSecurity permission.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[Grantor ]
+%[visit_definition]
+
+Users who have the ability to grant or deny permissions to
+users for objects. These are users who have any of the grant
+meta-permissions.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[Users authorized to modify their own authentication data]
+%[visit_definition]
+
+The role name says it all.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FMT{\_}SMR.1.2]
+%[visit_definition]
+
+The TSF shall be able to associate \emph{{[}principals]} with roles.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{class-fpt-protection-of-the-tsf}{}
+\pdfbookmark[3]{Class FPT: Protection of the TSF}{class-fpt-protection-of-the-tsf}
+\subsubsection*{Class FPT: Protection of the TSF}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fpt-amt-1-abstract-machine-testing}{}
+\pdfbookmark[4]{FPT{\_}AMT.1 Abstract machine testing}{fpt-amt-1-abstract-machine-testing}
+\subsubsection*{FPT{\_}AMT.1 Abstract machine testing}
+\begin{description}
+%[visit_definition_list_item]
+\item[FPT{\_}AMT.1.1 ]
+%[visit_definition]
+
+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.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fpt-fls-1-failure-with-preservation-of-secure-state}{}
+\pdfbookmark[4]{FPT{\_}FLS.1 Failure with preservation of secure state}{fpt-fls-1-failure-with-preservation-of-secure-state}
+\subsubsection*{FPT{\_}FLS.1 Failure with preservation of secure state}
+\begin{description}
+%[visit_definition_list_item]
+\item[FPT{\_}FLS.1.1 ]
+%[visit_definition]
+
+The TSF shall preserve a secure state when the following types of
+failures occur: \emph{{[}process termination, resource
+exhaustion and host restart]}.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fpt-rvm-1-non-bypassability-of-the-tsp}{}
+\pdfbookmark[4]{FPT{\_}RVM.1 Non-bypassability of the TSP}{fpt-rvm-1-non-bypassability-of-the-tsp}
+\subsubsection*{FPT{\_}RVM.1 Non-bypassability of the TSP}
+\begin{description}
+%[visit_definition_list_item]
+\item[FPT{\_}RVM.1.1 ]
+%[visit_definition]
+
+The TSF shall ensure that TSP enforcement functions are invoked
+and succeed before each function within the TSC is allowed to
+proceed.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fpt-sep-1-tsf-domain-separation}{}
+\pdfbookmark[4]{FPT{\_}SEP.1 TSF domain separation}{fpt-sep-1-tsf-domain-separation}
+\subsubsection*{FPT{\_}SEP.1 TSF domain separation}
+\begin{description}
+%[visit_definition_list_item]
+\item[FPT{\_}SEP.1.1 ]
+%[visit_definition]
+
+The TSF shall maintain a security domain for its own execution that
+protects it from interference and tampering by untrusted
+subjects.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[FPT{\_}SEP.1.2 ]
+%[visit_definition]
+
+The TSF shall enforce separation between the
+security domains of subjects in the TSC.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{fpt-stm-1-reliable-time-stamps}{}
+\pdfbookmark[4]{FPT{\_}STM.1 Reliable time stamps}{fpt-stm-1-reliable-time-stamps}
+\subsubsection*{FPT{\_}STM.1 Reliable time stamps}
+\begin{description}
+%[visit_definition_list_item]
+\item[FPT{\_}STM.1.1]
+%[visit_definition]
+
+The TSF shall be able to provide reliable time stamps for its own use.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-security-assurance-requirements}{}
+\pdfbookmark[1]{TOE security assurance requirements}{toe-security-assurance-requirements}
+\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{quote}
+
+\begin{longtable}[c]{|p{0.18\locallinewidth}|p{0.46\locallinewidth}|p{0.24\locallinewidth}|}
+\hline
+\textbf{
+Identification
+} & \textbf{
+Description
+} & \textbf{
+Direct dependencies
+} \\
+\hline
+\endhead
+
+\textbf{ACM}
+ &
+Configuration management (CM)
+ & \\
+\hline
+
+ACM{\_}CAP.1
+ &
+Version numbers
+ &
+None
+ \\
+\hline
+
+\textbf{ADO}
+ &
+Delivery and Operation
+ & \\
+\hline
+
+ADO{\_}IGS.1
+ &
+Installation, generation and start-up
+ &
+AGD{\_}ADM.1
+ \\
+\hline
+
+\textbf{ADV}
+ &
+Development
+ & \\
+\hline
+
+ADV{\_}FSP.1
+ &
+Informal Functional specification
+ &
+ADV{\_}RCR.1
+ \\
+\hline
+
+ADV{\_}RCR.1
+ &
+Representation correspondence:
+Information correspondence
+demonstration
+ &
+None
+ \\
+\hline
+
+\textbf{AGD}
+ &
+Guidance documents
+ & \\
+\hline
+
+AGD{\_}ADM.1
+ &
+Administrator guidance
+ &
+ADV{\_}FSP.1
+ \\
+\hline
+
+AGD{\_}USR.1
+ &
+User guidance
+ &
+ADV{\_}FSP.1
+ \\
+\hline
+
+\textbf{ATE}
+ & & \\
+\hline
+
+ATE{\_}IND.1
+ &
+Independent testing - conformance
+ &
+ADV{\_}FSP.1
+AGD{\_}ADM.1
+AGD{\_}USR.1
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-requirements-for-the-it-environment}{}
+\pdfbookmark[1]{Security requirements for the IT environment}{security-requirements-for-the-it-environment}
+\subsection*{Security requirements for the IT environment}
+
+ITITIT
+
+The following security requirements exist for the IT environment:
+
+The operating system is Windows 2000, Windows XP or Linux. Either all
+known security patches must have been installed.
+
+The Python Version is 2.3.2 or a compatible Bugfix release.
+
+The ZODB storage is FSStorage or XXX ... What else?.
+
+The client software must support ``protected authentication feedback''
+(FIA{\_}UAU.7), to at least not echo a user's credentials in plain text.
+
+One or more ``trusted paths'' to the TOE must be provided using secure
+proxies, such as an HTTPS proxy like Apache with SSL, or Pound.
+
+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 could be over a private network.
+
+To ensure a ``trusted path'' to the TOE, users of the TOE must use
+secure proxies correctly (for example, being sure to accept only
+valid server certificates with HTTPS).
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-requirements-for-the-non-it-environment}{}
+\pdfbookmark[1]{Security requirements for the non-IT environment}{security-requirements-for-the-non-it-environment}
+\subsection*{Security requirements for the non-IT environment}
+
+XXX I can't find any right here, maybe I should check cross-references, but it
+also looks like non-IT requirements are not mandatory.
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-summary-specification}{}
+\pdfbookmark[0]{TOE summary specification}{toe-summary-specification}
+\section*{TOE summary specification}
+
+
+%___________________________________________________________________________
+
+\hypertarget{toe-security-functions}{}
+\pdfbookmark[1]{TOE security functions}{toe-security-functions}
+\subsection*{TOE security functions}
+
+The major functions implemented by the TOE are:
+
+
+%___________________________________________________________________________
+
+\hypertarget{protection}{}
+\pdfbookmark[1]{Protection}{protection}
+\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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{authentication}{}
+\pdfbookmark[1]{Authentication}{authentication}
+\subsection*{Authentication}
+
+Zope provides a flexible authentication schema that by default supports HTTP
+Basic Auth and is extensible to support different data
+storages. Zope defines interfaces to implement different mechanisms for
+authentication data schemas as well as authentication mechanisms. By default
+Zope provides components to store username/password pairs in the ZODB and to
+authenticate with a username/password pair through HTTP Basic Authentication
+and FTP authentication.
+
+
+%___________________________________________________________________________
+
+\hypertarget{authorization-access-control}{}
+\pdfbookmark[1]{Authorization / Access Control}{authorization-access-control}
+\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'.
+
+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, e.g. for introducing groups.
+
+The default policy considers roles, grants and denials, location and principals
+to drive the decision. Permissions can be granted or denied to principals
+directly or by roles. Subjects can consider multiple principals if the
+execution of untrusted code is involved.
+
+If no principal is associated with a subject, the subject is allowed to perform
+any operation. The publisher component is required to bind an anonymous
+principal with the special role ``zope.Anonymous'' if no user has been
+authenticated.
+
+Every principal is automatically granted the ``zope.Anonymous'' role which can't be
+denied by any means. Also, every principal is granted the ``zope.Public''
+permission which can't be denied by any means.
+
+The 'zopepolicy' favors more specific declarations (permissions granted to
+principals over permissions granted to roles or grants that are nearer in terms
+of location) in contrast to more general (e.g. global declarations). Therefore
+it is possible to make exceptions for individuals from permissions granted to a
+role.
+
+
+%___________________________________________________________________________
+
+\hypertarget{auditing}{}
+\pdfbookmark[1]{Auditing}{auditing}
+\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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{transaction-management}{}
+\pdfbookmark[1]{Transaction management}{transaction-management}
+\subsection*{Transaction management}
+
+Most data is stored on persistent objects. The transaction machinery rolls back
+all data that is stored on persistent objects.
+
+
+%___________________________________________________________________________
+
+\hypertarget{undo}{}
+\pdfbookmark[1]{Undo}{undo}
+\subsection*{Undo}
+\begin{itemize}
+\item {}
+storage support
+
+\item {}
+can redo
+
+\item {}
+any level
+
+\item {}
+can undo a transaction, if there aren't any un-undone transactions that touch
+the same objects, if a conflict arises while changing the objects during
+undo, application level conflict resolution is used to try to resolve a
+conflict. if a conflict can't be resolved the undo can't be done.
+
+\end{itemize}
+
+Undo only allows the rollback of serial N last transaction to avoid integrity issues.
+
+
+%___________________________________________________________________________
+
+\hypertarget{publication-server}{}
+\pdfbookmark[1]{Publication / Server}{publication-server}
+\subsection*{Publication / Server}
+
+XXX get servers, protocols and publisher right
+
+The publisher allows users to communicate with the Zope server through a
+network, using standard protocols and client software like HTTP and browsers or
+FTP and FTP clients.
+
+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 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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{automated-tests}{}
+\pdfbookmark[1]{Automated Tests}{automated-tests}
+\subsection*{Automated Tests}
+
+Zope provides a suite of automated tests that allow the user to ensure that the
+security functionality implemented with a delivered package is consistent with
+the tests. Those tests can be run in offline mode.
+
+
+%___________________________________________________________________________
+
+\hypertarget{python-environment-xxx}{}
+\pdfbookmark[1]{Python Environment XXX}{python-environment-xxx}
+\subsection*{Python Environment XXX}
+
+As Zope relies on Python and the host environment to provide reliable time
+stamps, we regard auditing adjustments to the time being out of scope.
+Therefore external log mechanisms (Syslog on Unix hosts or the Event log on
+Windows hosts) should be consulted to detect those changes. (FPT{\_}STM.1)
+
+
+%___________________________________________________________________________
+
+\hypertarget{table-functions-to-security-functional-requirements-mapping}{}
+\pdfbookmark[1]{Table: Functions to Security Functional Requirements Mapping}{table-functions-to-security-functional-requirements-mapping}
+\subsection*{Table: Functions to Security Functional Requirements Mapping}
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.23\locallinewidth}|p{0.59\locallinewidth}|}
+\hline
+\textbf{
+Functions
+} & \textbf{
+Security Functional Requirements
+} \\
+\hline
+\endhead
+
+Protection
+ &
+FDP{\_}ACC.2, FDP{\_}ACF.1, FDP{\_}ETC.2, FDP{\_}ITC.1,
+FDP{\_}ITC.2, FDP{\_}ROL.1{\_}UNDO, FIA{\_}UAU.1, FMT{\_}MOF.1,
+FMT{\_}MSA.1, FMT{\_}SMR.1, FPT{\_}RVM.1, FPT{\_}SEP.1
+ \\
+\hline
+
+Authentication
+ &
+FIA{\_}AFL{\_}z.1, FIA{\_}ATD.1, FIA{\_}UAU.5, FIA{\_}UAU.6,
+FMT{\_}MSA.1
+ \\
+\hline
+
+Authorization
+ &
+FDP{\_}ACC.2, FDP{\_}ACF.1, FDP{\_}ETC.2, FDP{\_}ITC.1,
+FTP{\_}ITC.2, FDP{\_}RIP.1, FDP{\_}ROL.1{\_}Undo, FIA{\_}ATD.1,
+FIA{\_}UAU.1, FIA{\_}USB.1, FMT{\_}MOF.1, FMT{\_}MSA.1,
+FMT{\_}MSA.3, FMT{\_}SMR.1,
+ \\
+\hline
+
+Auditing
+ &
+FAU{\_}GEN.1, FAU{\_}GEN.2, FPT{\_}STM.1
+ \\
+\hline
+
+Transaction
+ &
+FDP{\_}ROL.2{\_}Transactions
+ \\
+\hline
+
+management
+ & \\
+\hline
+
+Undo
+ &
+FDP{\_}ROL.1{\_}Undo
+ \\
+\hline
+
+Publisher
+ &
+FIA{\_}UAU.1, FIA{\_}USB.1
+ \\
+\hline
+
+Automated Tests
+ &
+FPT{\_}AMT.1
+ \\
+\hline
+
+Python Environemnt
+ &
+FPT{\_}STM.1
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{table-security-functional-requirements-to-functions-mapping}{}
+\pdfbookmark[1]{Table: Security Functional Requirements to Functions Mapping}{table-security-functional-requirements-to-functions-mapping}
+\subsection*{Table: Security Functional Requirements to Functions Mapping}
+\begin{quote}
+
+\begin{longtable}[c]{|p{0.27\locallinewidth}|p{0.59\locallinewidth}|}
+\hline
+\textbf{
+SFR
+} & \textbf{
+Function
+} \\
+\hline
+\endhead
+
+FAU{\_}GEN.1
+ &
+Audit
+ \\
+\hline
+
+FAU{\_}GEN.2
+ &
+Audit
+ \\
+\hline
+
+FDP{\_}ACC.2
+ &
+Authorization, Protection
+ \\
+\hline
+
+FDP{\_}ACF.1
+ &
+Authorization, Protection
+ \\
+\hline
+
+FDP{\_}ETC.2
+ &
+Authorization, Protection, Synchronization
+ \\
+\hline
+
+FDP{\_}ITC.1
+ &
+Authorization, Protection, Synchronization
+ \\
+\hline
+
+FDP{\_}ITC.2
+ &
+Authorization, Protection, Synchronization
+ \\
+\hline
+
+FDP{\_}RIP.1
+ &
+Authorization
+ \\
+\hline
+
+FDP{\_}ROL.2{\_}Transactions
+ &
+Transaction management
+ \\
+\hline
+
+FDP{\_}ROL.1{\_}Undo
+ &
+Undo, Authorization, Protection
+ \\
+\hline
+
+FIA{\_}AFL{\_}z.1
+ &
+Authentication
+ \\
+\hline
+
+FIA{\_}ATD.1
+ &
+Authentication
+ \\
+\hline
+
+FIA{\_}UAU.1
+ &
+Publication, Authorization, Protection
+ \\
+\hline
+
+FIA{\_}UAU.5
+ &
+Authentication
+ \\
+\hline
+
+FIA{\_}UAU.6
+ &
+Authentication
+ \\
+\hline
+
+FIA{\_}USB.1
+ &
+Publication, Authorization
+ \\
+\hline
+
+FMT{\_}MOF.1
+ &
+Authorization, Protection, Authentication
+ \\
+\hline
+
+FMT{\_}MSA.3
+ &
+Authorization
+ \\
+\hline
+
+FMT{\_}SMR.1
+ &
+Authorization, Protection
+ \\
+\hline
+
+FPT{\_}AMT.1
+ &
+Automated Tests
+ \\
+\hline
+
+FPT{\_}RVM.1
+ &
+Protection
+ \\
+\hline
+
+FPT{\_}FLS.1
+ &
+Transaction management
+ \\
+\hline
+
+FPT{\_}SEP.1
+ &
+Protection
+ \\
+\hline
+
+FPT{\_}STM.1
+ &
+Python environment
+ \\
+\hline
+\end{longtable}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{assurance-measures}{}
+\pdfbookmark[1]{Assurance measures}{assurance-measures}
+\subsection*{Assurance measures}
+
+
+%___________________________________________________________________________
+
+\hypertarget{am-acm-configuration-management}{}
+\pdfbookmark[2]{AM{\_}ACM: CONFIGURATION MANAGEMENT}{am-acm-configuration-management}
+\subsubsection*{AM{\_}ACM: CONFIGURATION MANAGEMENT}
+
+A document describing the configuration management will be provided.
+
+
+%___________________________________________________________________________
+
+\hypertarget{am-ado-delivery-and-operation}{}
+\pdfbookmark[2]{AM{\_}ADO: DELIVERY AND OPERATION}{am-ado-delivery-and-operation}
+\subsubsection*{AM{\_}ADO: DELIVERY AND OPERATION}
+
+A document describing the delivery and operation of the TOE will be provided.
+
+
+%___________________________________________________________________________
+
+\hypertarget{am-adv-development}{}
+\pdfbookmark[2]{AM{\_}ADV: DEVELOPMENT}{am-adv-development}
+\subsubsection*{AM{\_}ADV: DEVELOPMENT}
+
+A functional specification and a RCR document will be provided.
+
+
+%___________________________________________________________________________
+
+\hypertarget{am-agd-guidance-documents}{}
+\pdfbookmark[2]{AM{\_}AGD: GUIDANCE DOCUMENTS}{am-agd-guidance-documents}
+\subsubsection*{AM{\_}AGD: GUIDANCE DOCUMENTS}
+
+The guidance documents AGD{\_}ADM and AGD{\_}USR will be provided.
+
+
+%___________________________________________________________________________
+
+\hypertarget{am-ate-tests}{}
+\pdfbookmark[2]{AM{\_}ATE: TESTS}{am-ate-tests}
+\subsubsection*{AM{\_}ATE: TESTS}
+
+No deliverable. Only independend testing from the evaluator is needed.
+
+
+%___________________________________________________________________________
+
+\hypertarget{pp-claims}{}
+\pdfbookmark[0]{PP claims}{pp-claims}
+\section*{PP claims}
+
+There are no PP claims.
+
+
+%___________________________________________________________________________
+
+\hypertarget{sof-claims}{}
+\pdfbookmark[0]{SOF claims}{sof-claims}
+\section*{SOF claims}
+
+There is no SOF claim here for EAL 1.
+
+
+%___________________________________________________________________________
+
+\hypertarget{rationale}{}
+\pdfbookmark[0]{Rationale}{rationale}
+\section*{Rationale}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-objectives-rationale}{}
+\pdfbookmark[1]{Security objectives rationale}{security-objectives-rationale}
+\subsection*{Security objectives rationale}
+\begin{description}
+%[visit_definition_list_item]
+\item[O.IA]
+%[visit_definition]
+
+This security objective is necessary to counter the threat T.IA
+because it requires that users must be accurately identified and
+authenticated or incorporate the anonymous principal.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+O.Delegation
+\begin{quote}
+
+This security objective is necessary to counter the threat 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.
+\end{quote}
+\begin{description}
+%[visit_definition_list_item]
+\item[O.Audit]
+%[visit_definition]
+
+This security objective is necessary to counter the threat T.AuditFake
+because it loggs security relevant events and thus supports an
+administrator in finding those events.
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[O.Protect]
+%[visit_definition]
+
+XXX
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[O.Access]
+%[visit_definition]
+
+This security objective is necessary to counter the threat T.Operation
+because it prevents performing operations on an object without haveing the
+correct permission.
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{table-mapping-of-threats-to-security-objectives}{}
+\pdfbookmark[2]{Table: Mapping of Threats to Security Objectives}{table-mapping-of-threats-to-security-objectives}
+\subsubsection*{Table: Mapping of Threats to Security Objectives}
+\begin{quote}
+\begin{quote}
+
+T.IA T.Perm T.Operation T.AuditFake T.Import T.RIP T.Transaction T.Undo T.USB T.Timestamps T.Trustedpath T.Host
+\end{quote}
+
+O.IA X
+O.Delegation X
+O.Audit X
+O.Protect
+O.Access X
+O.Integrity
+O.Attributes
+O.ManageRisk
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{security-requirements-rationale}{}
+\pdfbookmark[1]{Security requirements rationale}{security-requirements-rationale}
+\subsection*{Security requirements rationale}
+
+XXX
+
+
+%___________________________________________________________________________
+
+\hypertarget{choice-of-security-functional-requirements}{}
+\pdfbookmark[2]{Choice of security functional requirements}{choice-of-security-functional-requirements}
+\subsubsection*{Choice of security functional requirements}
+
+XXX
+
+
+%___________________________________________________________________________
+
+\hypertarget{justification-for-suitability-of-sfr-toe-security-objectives}{}
+\pdfbookmark[1]{Justification for suitability of SFR - TOE security objectives}{justification-for-suitability-of-sfr-toe-security-objectives}
+\subsection*{Justification for suitability of SFR - TOE security objectives}
+
+
+%___________________________________________________________________________
+
+\hypertarget{choice-of-toe-security-assurance-requirements}{}
+\pdfbookmark[2]{Choice of TOE security assurance requirements}{choice-of-toe-security-assurance-requirements}
+\subsubsection*{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}.
+
+
+%___________________________________________________________________________
+
+\hypertarget{evaluation-assurance-level-rationale}{}
+\pdfbookmark[1]{Evaluation Assurance Level rationale:}{evaluation-assurance-level-rationale}
+\subsection*{Evaluation Assurance Level rationale:}
+
+XXX review this paragraph please.
+
+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
+certification may effect Zope's degree of documentation and stabilize the good
+security history even more, maybe raising the interest for projects that
+require good security behaviour and seek free alternatives.
+
+XXX mention ``confidence''
+
+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.
+
+
+%___________________________________________________________________________
+
+\hypertarget{glossary}{}
+\pdfbookmark[0]{Glossary}{glossary}
+\section*{Glossary}
+\begin{description}
+%[visit_definition_list_item]
+\item[CC]
+%[visit_definition]
+
+Common Criteria (referenced as {[}CC])
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[SF]
+%[visit_definition]
+
+Security Function
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[SFP]
+%[visit_definition]
+
+Security Function Policy
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[SFR]
+%[visit_definition]
+
+Security Functional Requirement
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[ST]
+%[visit_definition]
+
+Security Targets
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[TOE]
+%[visit_definition]
+
+Target of Evaluation
+
+%[depart_definition]
+%[depart_definition_list_item]
+%[visit_definition_list_item]
+\item[TSF]
+%[visit_definition]
+
+TOE Security Functions
+
+%[depart_definition]
+%[depart_definition_list_item]
+\end{description}
+
+
+%___________________________________________________________________________
+
+\hypertarget{todo}{}
+\pdfbookmark[0]{TODO}{todo}
+\section*{TODO}
+
+
+%___________________________________________________________________________
+
+\hypertarget{general}{}
+\pdfbookmark[1]{General}{general}
+\subsection*{General}
+\begin{quote}
+\begin{itemize}
+\item {}
+Bibliographic references
+
+\item {}
+Numbering of sections would be fine
+
+\end{itemize}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{part-1}{}
+\pdfbookmark[1]{Part 1}{part-1}
+\subsection*{Part 1}
+\begin{quote}
+\begin{itemize}
+\item {}
+Threat agents (ctheune)
+
+\item {}
+TOE description (ctheune)
+
+\item {}
+TOE security functions (ctheune)
+
+\end{itemize}
+\end{quote}
+
+
+%___________________________________________________________________________
+
+\hypertarget{part-2}{}
+\pdfbookmark[1]{Part 2}{part-2}
+\subsection*{Part 2}
+\begin{quote}
+\begin{itemize}
+\item {}
+Rationale
+
+\item {}
+Security Objectives Rationale (zagy)
+
+\item {}
+Security Requirements Rationale (ctheune)
+
+\item {}
+TOE summary specification rationale
+
+\item {}
+PP claims rationale
+
+\end{itemize}
+\end{quote}
+
+\end{document}
More information about the Zope3-Checkins
mailing list