SVN: Zope3/trunk/doc/security/SecurityTarget.tex Completed the suitability analysis as indicated by observation 2.11.
Christian Theune <[email protected]>
| Newsgroups | gmane.comp.web.zope.zope3.cvs |
|---|---|
| Message-ID | <[email protected]> |
Log message for revision 81600:
Completed the suitability analysis as indicated by observation 2.11.
Re-arranged FIA_UAU.6 a bit to meet our abstractions for authentication
plugins.
Changed:
U Zope3/trunk/doc/security/SecurityTarget.tex
-=-
Modified: Zope3/trunk/doc/security/SecurityTarget.tex
===================================================================
--- Zope3/trunk/doc/security/SecurityTarget.tex 2007-11-07 17:07:03 UTC (rev 81599)
+++ Zope3/trunk/doc/security/SecurityTarget.tex 2007-11-08 09:58:30 UTC (rev 81600)
@@ -922,9 +922,9 @@
\item[FDP{\_}ACF.1.1]
The TSF shall enforce the \emph{Zope access control policy} to objects
-based on \emph{the interaction principal, the permission required for
-the operation and the grants of the privilege for that
-object or it's ancestor objects}.
+based on \emph{the interaction principals, the permission required for
+the operation and the privilege grants for that
+object or its ancestor objects}.
\item[FDP{\_}ACF.1.2]
@@ -1084,8 +1084,7 @@
The TSF may re-authenticate the user under the conditions
\begin{itemize}
\item {}
-If the credentials held by the user agent have expired due to
-a configurable time limit.
+If the authentication plugin considers a set of credentials expired or invalid.
\item {}
If the authenticated user does not have the required permissions to
@@ -1095,8 +1094,12 @@
\end{itemize}
+\textbf{Note:} As Zope uses a pluggable system to provide authentication
+support for various authentication schemes each scheme has the ability to
+decide whether a given set of credentials is expired. The conditions how this
+is decided is specific to the authentication schema and might be based on
+differing conditions or not be implemented at all.
-
\end{description}
@@ -1503,10 +1506,9 @@
To determine whether an operation under a given subject is allowed, Zope has an
authorization subsystem (aka access control). The authorization subsystem uses
-pluggable policies to allow the implementation of different rule sets. Zope
-provides a default security policy called ``zopepolicy''. The security policy
-considered for this certification is called ``sharing policy'' as implemented
-by the ``zc.sharing'' Python package.
+pluggable policies to allow the implementation of different rule sets. The ST
+provides a security policy called ``sharing policy'' which is configured by
+default. The policy is implemented by the ``zc.sharing'' Python package.
Policies implement a method `checkPermission' to determine whether the
requested access is allowed or not. Policies define the information required to
@@ -2120,7 +2122,7 @@
\cline{2-11}
FIA\_AFL\_z.1 & & \oh & & & & & \oh & & \\
\cline{2-11}
-FIA\_ATD.1 & & & & & \oh & & & & \\
+FIA\_ATD.1 & & \oh & \oh & & \oh & & & & \\
\cline{2-11}
FIA\_UAU.1 & & & & & & & \oh & & \\
\cline{2-11}
@@ -2146,8 +2148,6 @@
\cline{2-11}
FPT\_RVM.1 & \oh & & & & & & \oh & & \\
\cline{2-11}
-FPT\_FLS.1 & & & & & & \oh & & & \\
-\cline{2-11}
FPT\_SEP.1 & \oh & & & & & & & & \\
\cline{2-11}
FPT\_STM.1 & & & & & & & & & \oh \\
@@ -2158,6 +2158,21 @@
\subsubsection{Suitability of SF to meet the SFRs}
+\minisec{FAU\_GEN.1 --- Audit data generation}
+
+Audit data is generated by the \textbf{Auditing} subsystem. Zope's event
+framework is used for standardized event communication using an interface
+description conforming to the required data set. This interface is
+systematically enforced and guarantees that all events received provide the
+required data fields.
+
+\minisec{FAU\_GEN.2 --- User identity assocation}
+
+Events received by the \textbf{Auditing} subsystem are correlated by the
+Auditing subsystem to the current interaction (and thus the current
+principals). This guarantees that the user identity associated with an event
+happens and is correct.
+
\minisec{FDP\_ACC.2 --- Complete Access Control}
Complete access control is achieved by the \textbf{Protection} subsystem. The
@@ -2167,7 +2182,12 @@
When an interaction accesses a proxied object, the protection subsystem
becomes effective and regulates access.
+\minisec{FDP\_ACF.1 --- Security attribute based access control}
+The rules described for ``Security attribute based access control'' are
+implemented by the ``sharing policy'' as described by the
+\textbf{Authorization} subsystem.
+
\minisec{FDP\_ROL.2\_TRANSACTIONS --- Advanced Rollback}
The \textbf{Transaction management} of ZODB allows rollback of transaction. The
@@ -2190,8 +2210,20 @@
\textbf{Authentication} subsystem may not be able to distinguish two requests
to be different user initiated requests or started off at another point in the
application.
-
+\minisec{FIA\_ATD.1 --- User attribute definition}
+
+The user attributes as required by FIA\_ATD.1 are defined in Python interfaces
+by the \textbf{Authentication} and \textbf{Authorization} subsystems. All
+specific user definition plugins must adhere to those interfaces and provide a
+unique id for each principal, store credentials (specific to their
+authentication mechanism). The sharing policy as defined by the
+\textbf{Authorization} subsystem is responsible for storing the privilege
+grant information.
+
+The \textbf{Configuration} subsystem provides an implementation of those
+interfaces for definining the initial set of users.
+
\minisec{FIA\_UAU.1, FIA\_UID.1 --- Timing of authentication and identification}
The \textbf{Publication} subsystem detects provided credentials and existing
@@ -2218,12 +2250,15 @@
If an operation could not be performed due to missing permission grants, the
\textbf{Publication} subsystem may -- instead of denying further operation --
ask the user to provide other credentials to authenticate for a different
-principal.
-
-\emph{Note:} This is implemented by the same scheme that is used to initially
+principal. (This is implemented by the same scheme that is used to initially
retrieve credentials from a user when the operation could not be performed by
-the anonymous principal.
+the anonymous principal.)
+The \textbf{Authentication} subsystem is able to re-challenge a user to
+provide new credentials in the case that a given set of credentials is expired
+or invalid.
+
+
\minisec{FIA\_USB.1 --- User-Subject Binding}
When the \textbf{Publication} system sets up to perform an operation, it
@@ -2294,6 +2329,19 @@
Other roles are defined as privileges, too.
+\minisec{FPT\_AMT.1 --- Abstract machine testing}
+
+The \textbf{Automated tests} subsystem provides executable (Python) code that
+is used to verify that provided components adhere to the interfaces they
+implement.
+
+The tests are partially accompanied with documentation that explain their
+goals and the edge cases of specific situations.
+
+The tests for the ST can be run at any point in time without interfering with
+a running system and can therefore be used to prove that validity of the code
+in use.
+
\minisec{FPT\_RVM.1 --- Non-bypassability of the TSP}
The concept of the \textbf{Protection} system is to put a layer of protection
@@ -2312,6 +2360,13 @@
the Protection system will prevent the elevation of privileges by assuring that
the layer of security proxies is installed and effective.
+\minisec{FPT\_STM.1 --- Reliable time stamps}
+
+Reliable time stamps are provided through a Python API which relies on the
+correct system time provided by the operating system. The subsystem
+\textbf{Python environment} covers this requirement and is complemented by the
+requirement for the environment \textbf{RENV.Linux}.
+
\subsection{Assurance measures}
The assurance measures are selected in accordance to EAL 1. Additionally due to