[Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.txt -
just a checkpoint
Christian Theune
ct at gocept.com
Sun Oct 10 03:57:18 EDT 2004
Log message for revision 27874:
- just a checkpoint
Changed:
U Zope3/trunk/doc/security/SecurityTarget.txt
-=-
Modified: Zope3/trunk/doc/security/SecurityTarget.txt
===================================================================
--- Zope3/trunk/doc/security/SecurityTarget.txt 2004-10-10 07:24:06 UTC (rev 27873)
+++ Zope3/trunk/doc/security/SecurityTarget.txt 2004-10-10 07:57:18 UTC (rev 27874)
@@ -129,12 +129,6 @@
configuration files and dynamically via settings in the object database) within
an context to allow them performing operations on a selected set of objects.
-To make assignments between several permissions and several principals easy you
-can define roles. Those can be thought of as "hats" or "responsibilities" a
-user may have, where each responsibility grants the user a different *set* of
-permissions. A role exists of a list of permissions and can be granted to a
-principal within a context.
-
Principals are authenticated in various way 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
@@ -272,7 +266,7 @@
Permission A permission is a name guarding an operation.
- Permission grants A permission grant associates a role with a
+ 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.
@@ -350,9 +344,9 @@
The following threats against the assets have been identified:
- ============== =============================================== ====================
+ ============== ================================================== =======================================================================
Threat Threat description Asset
- ============== =============================================== ====================
+ ============== ================================================== =======================================================================
T.IA An attacker might impersonate an authorized Principal
principal without providing the necessary
credentials.
@@ -391,7 +385,7 @@
T.Host An attacker might use Python functions that Host, Object
result in direct access to the host environment
therefore compromising the host and Zope itself.
- ============== =============================================== ====================
+ ============== ================================================== =======================================================================
Organisational security policies
--------------------------------
@@ -575,8 +569,8 @@
The TSF shall enforce the following rules to determine
if an operation among controlled subjects and controlled objects is
allowed: *[
-
- - Access is denied if there is a denial for the subject's
+
+ - Access is denied if there is a denial for the subject's
principal for the required permission on the object.
- Access is allowed if there is a grant and there is not a denial
@@ -788,17 +782,12 @@
FIA_UAU.5 Multiple authentication systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-XXX
- Digest would be nice to have
-
-
FIA_UAU.5.1
The TSF shall provide *[extensible support for multiple
authentication mechanisms. The default mechanism uses login names
- and passwords in combination with HTTP Baic Authorization and FTP
+ and passwords in combination with HTTP Basic Authorization and FTP
authorization]*
-
FIA_UAU.5.2
The TSF shall authenticate any users claimed identity according to
the *[system configuration, provided credentials, such as a
@@ -899,7 +888,7 @@
FMT_SMR.1.1
The TSF shall maintain *[
- authorized administrator
+ Authorized administrator
Users who can perform system-wide security functions. These are
people who have the zope.ManageSecurity permission.
@@ -908,7 +897,7 @@
users for objects. These are users who have any of the grant
meta-permissions.
- users authorized to modify their own authentication data
+ Users authorized to modify their own authentication data
The role name says it all.
]*.
@@ -1035,31 +1024,145 @@
TOE security functions
----------------------
-Zope's security functions are provided via independent subsystems:
+The major functions implemented by the TOE are:
-- permission declarations
+Protection
+----------
-- 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.
-- authentication
+ Protection
+ ^^^^^^^^^^
-- authorization (aka access)
+ XXX To cover: FDP_ACC.2, FDP_ACF.1, FDP_ETC.2, FDP_ITC.1, FDP_ITC.2,
+ FDP_ROL.1_UNDO, FAU_UAU.1, FMT_MOF.1, FMT_MSA.1, FMT_SMR.1, FPT_RVM.1,
+ FPT_SEP.1
-- auditing [Christian, done?]
+ The protection subsystem is responsible for controlling the access of
+ interactions (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.
-- synchronization
+ Basic objects are immutable objects that contain only immutable
+ subobjects. Examples if basic objects include:
-- transaction management
+ - Strings,
-- undo
+ - Integers (long and normal),
-- publisher
+ - Floating-point objects,
-- automated tests [Christian, done?]
+ - Date-time objects,
-Additionally the Python and host environment provide functionality required by
-the security functions.
+ - Boolean objects (True and False), and
+ - The special (nil) object, None.
+
+ Subjects only have access to basic objects and proxied objects.
+
+ For the purposes of the protection system, all operations can be
+ reduced to one of two kinds of operations:
+
+ - Read the value of a named attribute
+
+ - Write the value of a named attribute
+
+ Higher-level operations are reduced to these low-level operations. For example,
+ to look up a key in a mapping object, we first execute read operation on the
+ '__getitem__' attribute. The value of the '__getitem__' attribute is the
+ Python method for looking up a key. To actually call the method, we need to
+ access it's '__call__' attribute.
+
+Authentication
+--------------
+
+Zope provides a flexible authentication schema that by default supports HTTP
+Basic Auth, HTTP Cookie auth and is extensible to support different data
+storages...
+
+Authorization
+-------------
+
+Zope provides authorization mechanisms that decide wether an operation under a
+given subject is allowed...
+
+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 provided infrastructure (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.
+
+Transaction management
+----------------------
+
+Undo
+----
+
+Publisher
+---------
+
+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 as unit tests in offline mode.
+
+ Automated tests
+ ^^^^^^^^^^^^^^^
+
+ One objective of the Zope 3 effort is to provide a good coverage of all
+ functions with automated tests to support the agile software development process.
+ Those are tests that are written in Python and run as test scenarios to assure
+ correct functioning of components with respect to their declared interfaces.
+
+ A subset of those tests is the set of tests that cover the security functions.
+ Zope 3 provides a program to run those tests and gather feedback about the
+ result. This is done as an offline operation outside of Zope itself.
+
+ The tests are provided as modules called "tests" that reside
+ within the packages they provide tests for. The provided utility is able to
+ run only subsets of those specific to their location within the Zope package
+ hierarchy.
+
+ Those tests cover the abstract machine testing as described in FPT_AMT.1.
+
+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+
+- permission declarations [isn't needed IMHO, Christian]
+
+X protection
+
+X authentication [Christian, ]
+
+X authorization (aka access)
+
+X auditing [Christian, done?]
+
+X transaction management
+
+X undo
+
+X publisher
+
+X automated tests [Christian, done?]
+
+Additionally the Python and host environment provide functionality
+required by the security functions.
+
+XXX Helpful points to start: SecurityFramework in Wiki
+
Definitions
^^^^^^^^^^^
@@ -1074,15 +1177,12 @@
ability to perform one or more operations.
-
-Christian
-
The auditing subsystem
^^^^^^^^^^^^^^^^^^^^^^
Zope provides an auditing system that listens for events within Zope according
-to the SFRs described above. It is implemented using the internal "event
-service" of Zope 3 to subscribe to the audit relevant events and log them
+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 provided infrastructure (event listener + logger)
satisfies the requirements as described in FAU_GEN.1 and FAU_GEN.2.
@@ -1104,7 +1204,7 @@
Following events are supported by Zope:
-X - IAuditStartup, IAuditShutdown for startup and shutdown of the audit
+ - IAuditStartup, IAuditShutdown for startup and shutdown of the audit
function (FAU_GEN.1)
- IOperationAllowed, IOperationDenied for a successful/unsuccessful
@@ -1160,109 +1260,6 @@
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)
-Automated tests
-^^^^^^^^^^^^^^^
-
-One objective of the Zope 3 effort is to provide a good coverage of all
-functions with unit tests to support the agile software development process.
-Those are tests that are written in Python and run as test scenarios to assure
-correct functioning of components with respect to their declared interfaces.
-
-A subset of those tests is the set of tests that cover the security functions.
-Zope 3 provides a program to run those tests and gather feedback about the
-result. This is done as an offline operation outside of Zope itself.
-
-The tests are provided distributed as sub-packages called "test" that reside
-within the packages they provide tests for. The provided utility is able to
-run only subsets of those specific to their location within the Zope package
-hierarchy.
-
-Those tests cover the abstract machine testing as described in FPT_AMT.1.
-
-Jim
-
-
-Protection subsystem
-^^^^^^^^^^^^^^^^^^^^
-
-XXX To cover: FDP_ACC.2, FDP_ACF.1, FDP_ETC.2, FDP_ITC.1, FDP_ITC.2,
-FDP_ROL.1_UNDO, FAU_UAU.1, FMT_MOF.1, FMT_MSA.1, FMT_SMR.1, FPT_RVM.1,
-FPT_SEP.1
-
-The protection subsystem is responsible for controlling the access of
-interactions (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
-object are performed through the security proxies.
-
-Basic objects are immutable objects that contain only immutable
-subobjects. Examples if basic objects include:
-
-- Strings,
-
-- Integers (long and normal),
-
-- Floating-point objects,
-
-- Date-time objects,
-
-- Boolean objects (True and False), and
-
-- The special (nil) object, None.
-
-Subjects only have access to basic objects and proxied objects.
-
-For the purposes of the protection system, all operations can be
-reduced to one of two kinds of operations:
-
-- Read the value of a named attribute
-
-- Write the value of a named attribute
-
-Higher-level operations are reduced to these low-level operations. For
-example, to look up a key in a mapping object, we first execute read
-operation on the '__getitem__' attribute. The value of the
-'__getitem__' attribute is the Python method for looking up a key.
-To actually call the method, we need to access it's '__call__
-
-
-
-
-
-
-
-
-Steve
-
-
-
-
-
-
-
-
-
-
-Jim
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Assurance measures
------------------
@@ -1377,9 +1374,6 @@
TSF
TOE Security Functions
-Acquisition
- XXX Jim? A two sentence description of acquisition in Zope 3 that makes sense? :)
-
TODO
====
@@ -1449,52 +1443,25 @@
systems on the logging system.
-
-
Questions to Zope 3 Dev
=======================
-FMT_MSA.3.1
- Is "restrictive" the thing we do when nothing else is specified?
-
-FTP_TRP.1.1
- Is the import/export feature going to be local only? What would
- a "disctinct" communication path be if not local?
-
FAU_GEN.1.2
Other audit data to store?
-FDP_ITC.2
- What other rules shall be applied?
-
-FIA_UAU.5
- Provide information about the out-of-the-box authentication
- mechanisms that are delivered with Zope X3.
-
-FPT_TDC.1.1
- Describe data types
-
-FPT_TDC.1.2
- Describe the rules that apply for interpretation of data / data formats
-
What about the "nice to have" functions?
FIA_SOS.1 : password effectiveness check
FIA_AFL.1 : authentication failure counter
-
Should we refer to some "hard coded" permissions that will be required to perform
-certain tasks? (e.g. for adding/deleting users, granting permissions ...)
+certain tasks? (e.g. for adding/deleting principals, granting permissions ...)
This will make the evaluation more specific and/but easier.
* Please look through the security functions (chapter TOE summary specification)
and check if there is wrong terminology. Also we probably will have to implement
some of the stuff i'm claiming there. :)
-* Do we want to include ZEO? I think FPT_TDC.1 is useful for that, but some
- other points are relevant as well. E.g. reliable time stamps (maybe they should
- be generated by a/the server ...)
-
* Jim talked about something that is described in FMT_SMR.3:
"Assuming roles requires that an explicit request is given to the TSF to assume a Role".
Are we going to have that?
@@ -1502,8 +1469,3 @@
* In TSF_AUD (summary specification): I'm guessing about the function of the security audit
logger (doesn't sound too hard, maybe I should/could write that thing)
-Questions to TUV
-================
-
- - Is there a standard format for logging audit data. maybe one that is
- usable by audit software?
More information about the Zope3-Checkins
mailing list