[Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.tex Completed the suitability analysis as indicated by observation 2.11.

Christian Theune ct at gocept.com
Thu Nov 8 04:58:31 EST 2007


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



More information about the Zope3-Checkins mailing list