# [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.
+

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

`