Make Zope fit for Common Critera

Status

Abandoned (The CC project was cancelled in May 2008)

Author

Christian Theune

Problem/Proposal

Zope 3 is sponsored a common criteria certification. To be certified we will have to add some security related functionality and I propose to add this functionality as listed in the next section.

Proposed Solution

According to our specification document we wanted and need to support several functions.

Provide optional CC compliance mode

To allow users to decide whether they want to make use of the overhead of the CC compliance functions, we implement a switch that turns the functions with the most overhead off. The specific set of functions controlled by this feature will depend on the runtime impact of each feature.

Zope must generate an easily understandable and very visible log statement, eventually also a notice on the process information page about whether it is in certification mode or not and eventually also say which systems were disabled.

New security policy

Zope Corporation offered to sponsor a different security policy based on priviledges instead of roles. We decided that this is a much simpler model and easier to explain but still powerful enough to be useful. This policy needs to be integrated into Zope.

Audit log

An audit log that records events, complying to the CC functional requirements:

• Generate record for the events: Startup and shutdown of audit functions,
• Each record contains at least the information: date and time, type of event, subject identity (principal/user) and outcome (success or failure)
• For each audit event type there may be additional fields, for example the ID of the corresponding interaction. (XXX do we have a sensible ID for those?)

The log will be implemented as an event subscriber using a custom file format. Additional events will be introduced as stated by the functional requirements document. The log filename will be configured via zope.conf.

Subset residual information protection

Check for functions deallocating security objects that required dereferencing on other objects.

Implementation option: Events and subscribers that remove referenced objects. This is likely a very expensive function.

Authentication failure handling

Zope shall be able to detect consecutive unsuccessful authentication attempts for a single login name (with no intermediate successfull attempts). The authentication shall be disabled for this login for a configurable amount of time. The amount of consecutive unsuccessful attempts shall be configurable as well.

This might be possible to implement in PAU, which will make us require PAU to run certified.

Credential time limit

Zope shall re-authenticate users after a configurable time-limit for their credentials.

This might be solvable by changing the PAU?

Management of security attributes

I'm not sure we have to do anything for it, but I leave it in here as a reminder.

Failure with preservation of state

I'm not sure we node code here either. It might be that we have to think about and prove the fitness of Zope to stay secure in the events of: process termination, resource exhaustion and/or host restart

Risks

• Inspite the configuration option, Zope might still get significantly slower. We have to avoid that.