Security Manager

Security manager requirements

• A zero configuration mode - if installed in an environment that have not enabled any security manager, we can install the policy file and a security manager directly.
• Advanced configuration mode - the administrator will need to install our policy.  This mode is necessary to let XWiki live on the same servlet container as other servlets that use the security manager.
• User scripts should run in an unprivileged domain.
• API modules may be used to raise the privileges of running scripts.
• It should be possible to associate different sets of privileges to different API calls and maybe different privileges depending on the user's rights.

Implementation ideas

• There would be a main "xwiki platform" domain, which have the maximum privileges assigned to XWiki.  Most platform code would exist in this domain.
• There would be an unprivileged "script" domain, which have no privileges.  Script engines would exist in this domain.
• It should be possible to define additional domains.  Such domains will be entered via a "DomainEntrance" object that calls 'doPrivileged'.  Obviously, these objects must not be accessible from the "script" domain.  (The classes must have private constructors so that the permission 'java.lang.reflect.ReflectPermission "suppressAccessChecks"' will be required for instantiation.)  These objects are used by the API modules to raise the privileges of running scripts.

Domains

The domains must be specified as one policy per jar file.

Policy per jar file

To simplify maintenance of the policy file, we employ symbolic names for domains.  Then, each xwiki platform component may include a file that names the domain its jar-file should be placed in.  It must also be possible to specify domain for the dependencies.  The default should be to not associate a jar-file with any particular policy (i.e., it will have minimum privileges).

The actual policies are specified by the project corresponding to the component xwiki-security-domain.

A maven plugin is employed to generate the final policy file.

Domain specification file

file name: domain_specification.txt

format:

<groupId>:<artifactId>[:<version>] <symbolic domain name>

Extended policy file format

Extend the standard policy file format with grant entries on the form:

grant domainId "xwiki-platform" {
      permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

The policy generator mojo will process the policy file and replace such entries with one 'grant codeBase' entry per jar file based on the domain specification files.

Policy generator tool

• Should run when building the war file (xwiki-enterprise-web).

• Must only read domain specifications from jar-files corresponding directly to modules specified in the xwiki-platform-core top level project.

Custom Domain Combiner

To optimize security checks, it is possible to use a custom DomainCombinator.  It is, however, not possible to enforce domain boundaries using a custom DomainCombinator, as it is always possible to discard the current domain combinator by calling 'doPrivileged'.  Also, the system should work also without a domain combiner, as installing one requires the very powerful permission java.security.SecurityPermission "createAccessControlContext" (which in practice is equivalent to AllPermissions).

Road Map

• Tool for processing domain specifications and extended policy files to produce one policy file for XWiki with one 'grant codeBase' entry per jar-file.
• Defining domains.
• Integrating domains with API modules.