[Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.tex -
Prepared for final version that will be released to the TUV.
Christian Theune
ct at gocept.com
Fri Apr 21 08:23:18 EDT 2006
Log message for revision 67206:
- Prepared for final version that will be released to the TUV.
Changed:
U Zope3/trunk/doc/security/SecurityTarget.tex
-=-
Modified: Zope3/trunk/doc/security/SecurityTarget.tex
===================================================================
--- Zope3/trunk/doc/security/SecurityTarget.tex 2006-04-21 11:49:12 UTC (rev 67205)
+++ Zope3/trunk/doc/security/SecurityTarget.tex 2006-04-21 12:23:17 UTC (rev 67206)
@@ -23,7 +23,10 @@
\hypersetup{
pdftitle={Zope 3.3 Common Criteria Evaluation},
-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}}
+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};Christian Zagrodnick
+{\textless}cz at gocept.com{\textgreater}}
}
\subject{Security Target}
@@ -37,9 +40,9 @@
\begin{description}
\item[Document Title:] Zope 3.3 Common Criteria Evaluation Security Target
\item[DocumentID:] \$Id: SecurityTarget.tex 65684 2006-03-01 22:40:30Z ctheune \$
- \item[Version:] \$Rev: 65684 \$ (Draft)
- \item[Status:] Draft
- \item[Date:] \$Date: 2006-03-01 23:40:30 +0100 (Mi, 01 Mär 2006) \$
+ \item[Version:] \$Rev: 65684 \$
+ \item[Status:] Final
+ \item[Date:] \$Date: 2006-03-01 23:40:30 +0100 (Mi, 01 Mär 2006) \$
\item[Author:] Christian Theune, ct at gocept.com
\item[Author:] Steve Alexander, steve at catbox.net
\item[Author:] Jim Fulton, jim at zope.com
@@ -394,7 +397,9 @@
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.
+causing operations within the TOE to be performed. The terms ``subject'' and
+``interaction'' can be used interchangeably for the purpose of this
+certification.
%___________________________________________________________________________
@@ -448,11 +453,9 @@
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 XXX happens.
+object does not provide the ISharing interface the next object in the chain of
+ancestors that provides ISharing will be considered for policy decisions.
-% We are not talking about adapters or adapting here. An objects provides
-% ISharing if there is an adapter.
-
%___________________________________________________________________________
@@ -957,18 +960,17 @@
\item[FDP{\_}ROL.2.1 ]
-The TSF shall permit \emph{the rollback of all
-operations on all objects}.
+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}.
+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 may not apply to cached data created during the
-course of a transaction.
+\textbf{Note:} This statement does not apply to non-persistent data created
+during the course of a transaction.
\end{description}
@@ -1293,14 +1295,13 @@
\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.
+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.
+The TSF shall enforce separation between the security domains of subjects in
+the TSC.
\end{description}
@@ -1337,9 +1338,6 @@
Identification & Description & Direct dependencies\\
\midrule \endhead
- \textbf{ACM} & Configuration management (CM) & \\
- ACM{\_}CAP.1 & Version numbers & None \\
-
\textbf{ADO} & Delivery and Operation & \\
ADO{\_}IGS.1 & Installation, generation and start-up & AGD{\_}ADM.1 \\
@@ -1353,7 +1351,7 @@
\textbf{AGD} & Guidance documents & \\
AGD{\_}ADM.1 & Administrator guidance & ADV{\_}FSP.1 \\
- AGD{\_}USR.1 & User 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 \\
@@ -1454,11 +1452,10 @@
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.
-If no principal is associated with a subject, the subject 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.
@@ -1528,7 +1525,7 @@
%___________________________________________________________________________
-\subsection{Automated Tests}
+\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
@@ -1539,7 +1536,7 @@
-\subsection{Python Environment}
+\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
@@ -1551,20 +1548,9 @@
\section{Assurance measures}
-
%___________________________________________________________________________
-
-\subsection{AM{\_}ACM: CONFIGURATION MANAGEMENT}
-
-A document describing the configuration management will be provided.
-
-
-%___________________________________________________________________________
-
-
-
\subsection{AM{\_}ADO: DELIVERY AND OPERATION}
A document describing the delivery and operation of the TOE will be provided.
@@ -1575,7 +1561,7 @@
\subsection{AM{\_}ADV: DEVELOPMENT}
-A functional specification, a RCR document and an informal security policy model
+A functional specification, an RCR document and an informal security policy model
(ADV\_SPM.1) will be provided.
%___________________________________________________________________________
@@ -1617,7 +1603,7 @@
\section{Security objectives rationale}
-The following table shows that all threads and assumptions are covered
+The following table shows that all threats and assumptions are covered
by a security objectives.
\begin{longtable}{rRRRRRRRRRRRRRRR}
@@ -1645,7 +1631,7 @@
\end{longtable}
The following list explains why the objectives cover
-the threads and assumptions.
+the threats and assumptions.
\begin{description}
@@ -1722,6 +1708,8 @@
\section{Security requirements rationale}
+The following table shows that all objectices are covered by security
+functions.
\begin{longtable}{rRRRRRRRR}
\toprule
@@ -1736,7 +1724,6 @@
FIA\_AFL\_z.1 & & & & \oh & & & & \\
FIA\_ATD.1 & \oh & \oh & \oh & & \oh & & & \\
FIA\_UAU.1 & \oh & & & & & & & \\
-FIA\_UAU.5 & \oh & & & & & & & \\
FIA\_UAU.6 & \oh & & & & & & & \\
FIA\_UID.1 & \oh & & & & & & & \\
FIA\_USB.1 & \oh & & & & & & & \\
@@ -1767,7 +1754,6 @@
FIA\_AFL\_z.1 & FIA\_UAU.1 \\
FIA\_ATD.1 & -- \\
FIA\_UAU.1 & FIA\_UID.1 \\
-FIA\_UAU.5 & -- \\
FIA\_UAU.6 & -- \\
FIA\_UID.1 & -- \\
FIA\_USB.1 & FIA\_ATD.1 \\
@@ -1784,7 +1770,7 @@
\caption{SFR Dependency Analysis}
\end{longtable}
-All dependencies required by the chosen SFRs are covered. See table XXX.
+All dependencies required by the chosen SFRs are covered.
\subsection{O.IA --- Identification and authentication}
@@ -1804,7 +1790,7 @@
Depending on the communication channel, the system selects a
suitable authentication mechanism to ask a user for his
- credentials. (FIA\_UAU.5)
+ credentials.
If an authenticated user does not have enough permission grants to
perform an operation, he might get the chance to authenticate with
@@ -1895,8 +1881,11 @@
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 (security
- proxies) for accessing TOE objects from external entities. (FIA\_RVM.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}
@@ -1917,16 +1906,18 @@
\subsection{O.ManageRisk --- Provide choice of flexibility versus security}
- Additionally 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 to trade off between
- functionality of their code and the level of trust they have to gain from
- administrators installing their extensions. FPT\_SEP.1 supports the
+ 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.
-\section{TOE Summary specification rationale}
+\newpage
+\section{TOE summary specification rationale}
+
\subsection{Security functions rationale}
\begin{longtable}{rRRRRRRRRRR}
@@ -1942,7 +1933,6 @@
FIA\_AFL\_z.1 & & \oh & & & & & \oh & & \\
FIA\_ATD.1 & & & & & \oh & & & & \\
FIA\_UAU.1 & & & & & & & \oh & & \\
-FIA\_UAU.5 & & \oh & & & & & \oh & & \\
FIA\_UAU.6 & & \oh & & & & & \oh & & \\
FIA\_UID.1 & & & & & & & \oh & & \\
FIA\_USB.1 & & & & & & & \oh & & \\
@@ -1957,7 +1947,7 @@
FPT\_SEP.1 & \oh & & & & & & & & \\
FPT\_STM.1 & & & & & & & & & \oh \\
\bottomrule
- \caption{Security Functions Rationale} % XXX
+ \caption{Security Functions Rationale}
\end{longtable}
@@ -1981,7 +1971,7 @@
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 (operation), there is no
+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.
@@ -2007,8 +1997,6 @@
the user to provide sufficient credentials for authentication and
identification.
-\minisec{FIA\_UAU.5 --- Multiple Authentication Systems}
-
The \textbf{Publication} and \textbf{Authentication} subsystems work together
to identify a meaningful way of asking a user for his credentials.
More information about the Zope3-Checkins
mailing list