[Zope3-checkins] SVN: Zope3/trunk/doc/security/ - added artefacts
and draft texts
Christian Theune
ct at gocept.com
Fri Dec 2 11:46:41 EST 2005
Log message for revision 40487:
- added artefacts and draft texts
Changed:
A Zope3/trunk/doc/security/artefacts/
A Zope3/trunk/doc/security/artefacts/rationales.sxc
A Zope3/trunk/doc/security/drafts/
A Zope3/trunk/doc/security/drafts/HighlevelDesign.txt
A Zope3/trunk/doc/security/drafts/README.txt
A Zope3/trunk/doc/security/drafts/SecurityTarget-relicts.txt
-=-
Added: Zope3/trunk/doc/security/artefacts/rationales.sxc
===================================================================
(Binary files differ)
Property changes on: Zope3/trunk/doc/security/artefacts/rationales.sxc
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: Zope3/trunk/doc/security/drafts/HighlevelDesign.txt
===================================================================
--- Zope3/trunk/doc/security/drafts/HighlevelDesign.txt 2005-12-02 16:46:27 UTC (rev 40486)
+++ Zope3/trunk/doc/security/drafts/HighlevelDesign.txt 2005-12-02 16:46:40 UTC (rev 40487)
@@ -0,0 +1,114 @@
+
+ Protection (PROTECTION)
+ ^^^^^^^^^^^^^^^^^^^^^^^
+ 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.
+
+ 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__' attribute.
+
+ 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 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.
+
+ Annotation: The ZODB assures that timestamps for transactions increase
+ monotonously with at least one microsecond since the last to work around
+ compromised clocks.
+
+ XXX talk about the format here
+
+ The events are defined outside the TSC within ZCML configuration statements
+ within the other Zope packages that are relevant for the events defined by the
+ SFRs.
+
+ Events supported by Zope
+ ************************
+
+ Following events are supported by Zope:
+
+ - IAuditStartup, IAuditShutdown for startup and shutdown of the audit
+ function (FAU_GEN.1)
+
+ - IOperationAllowed, IOperationDenied for a successful/unsuccessful
+ request to perform an operation on an object covered by the SFP
+ (FAU_ACF.1)
+
+ - IExportSuccess, IExportFailure for a successful/unsuccessful attempt to
+ export user data. (FDP_ETC.2)
+
+ - IImportSuccess, IImportFailure which detail imported security
+ attributes for a successfull/unsuccessfull attempt to import user data
+ (FDP_ITC.1, FDP_ITC.2)
+
+ - ITransactionAbortSuccess, ITransactionAbortFailure for a
+ successfull/unsuccessfull attempt to abort a transaction.
+ (FDP_ROL.2_TRANSACTIONS)
+
+ - IUndoSuccess, IUndoFailure for a successful/unsuccessful attempt to
+ undo former transactions within Zope. (FDP_ROL.1_UNDO)
+
+ - IFailedAuthenticationThresholdfor surpassing the threshold of
+ authentication failures and IAuthenticationFailureReset for
+ re-enabling a disabled login name after the configured period of time.
+ (FIA_AFL_z.1)
+
+ - IAuthenticationFailure for unsuccessful use of the authentication
+ mechanism. (FIA_UAU.1)
+
+ - IAuthenticationDecision for a final authentication decision (FIA_UAU.5)
+
+ - IReauthenticationFailure for unsuccessful re-authentication attempts
+ (FIA_UAU.6)
+ XXX Could that be covered by IAuthenticationFailure? Or is
+ this maybe a derived interface?
+
+ - IUSBFailure for unsuccessful binding of user security attributes to an
+ interaction (FIA_USB.1) XXX argh ... i wonder about an actual example
+ for that ...
+
+ - IAuthenticationManagement for changes to the authentication functions
+ (like adding/removing principals, exchanging authentication modules
+ ...) (FMT_MOF.1) XXX not required by minimal auditing
+
+ - ISecurityAttributeModification for modifications to security
+ attributes (grants, denies, login names, passwords) (FMT_MSA.1,
+ FMT_SMR.1) XXX FMT_MSA.1 is not required by minimal auditing
+
Property changes on: Zope3/trunk/doc/security/drafts/HighlevelDesign.txt
___________________________________________________________________
Name: svn:keywords
+ Id Rev Date
Name: svn:eol-style
+ native
Added: Zope3/trunk/doc/security/drafts/README.txt
===================================================================
--- Zope3/trunk/doc/security/drafts/README.txt 2005-12-02 16:46:27 UTC (rev 40486)
+++ Zope3/trunk/doc/security/drafts/README.txt 2005-12-02 16:46:40 UTC (rev 40487)
@@ -0,0 +1,2 @@
+This directory contains various information that is only drafted and does
+not correspond to an official document (yet).
Property changes on: Zope3/trunk/doc/security/drafts/README.txt
___________________________________________________________________
Name: svn:keywords
+ Id Rev Date
Name: svn:eol-style
+ native
Added: Zope3/trunk/doc/security/drafts/SecurityTarget-relicts.txt
===================================================================
--- Zope3/trunk/doc/security/drafts/SecurityTarget-relicts.txt 2005-12-02 16:46:27 UTC (rev 40486)
+++ Zope3/trunk/doc/security/drafts/SecurityTarget-relicts.txt 2005-12-02 16:46:40 UTC (rev 40487)
@@ -0,0 +1,84 @@
+These are a couple of relicts, questions and stuff that might be interesting
+in the future, but isn't right now
+
+What about the "nice to have" functions?
+----------------------------------------
+
+ FIA_SOS.1 : password effectiveness check
+ FIA_AFL.1 : authentication failure counter
+
+FAU_GEN.1.2
+-----------
+
+ Other audit data to store?
+
+* 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?
+
+* 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)
+
+- Talk about caching of security data
+
+Stuff I don't want to throw away
+================================
+
+Definitions
+-----------
+
+Principal
+ An object, managed by an Authentication service that
+ represents a user of the system. Principal have
+ system-unique identifiers that aree used by other systems to maintain
+ information about them.
+
+Permission
+ An object, managed by the Zope application that represents the
+ ability to perform one or more operations.
+
+Questions to Zope 3 Dev
+=======================
+
+Should we refer to some "hard coded" permissions that will be required to perform
+certain tasks? (e.g. for adding/deleting principals, granting permissions ...)
+This will make the evaluation more specific and/but easier.
+
+Nice to have / Future
+=====================
+
+ * FPT_TST is mostly handled by unit tests. What we don't handle is
+ data integrity. This might be something to consider for future
+ evaluations.
+
+ * FTA_TAH.1 TOE access history
+
+- It would be useful, when time allows (hehe) to abstract the security
+ policy into a profile and then see if other security profiles could
+ be "substituted".
+
+- We will need to define events that the auditing system can subscribe
+ to to do what it wants. Ideally, these events should not be defined
+ by the auditing system, so as not to create dependencies of other
+ systems on the logging system.
+
+- XXX we might want to think about realigning our terminology
+ (Access/protection/authorization)
+
+- The TOE will not have TTW created (untrusted) and stored code.
+ So, no TTW templates.
+
+- There should be some advice somewhere of the importance of having
+ universal (as opposed to system) principal and permission
+ identifiers if "export of user data with security attributes" is
+ supported. We might want to think about using guids in auth
+ services.
+
+FMT_MSA.1
+---------
+
+XXX
+ In later versions of the TOE we will need to specify semantics
+ of self registration (and authenticated users who are strangers,
+ and thus "untrusted")
+
Property changes on: Zope3/trunk/doc/security/drafts/SecurityTarget-relicts.txt
___________________________________________________________________
Name: svn:keywords
+ Id Rev Date
Name: svn:eol-style
+ native
More information about the Zope3-Checkins
mailing list