Dynamic groups. Advances. Part II

Though dynamic group usecase described in documentation looks reasonable (but has some limitations), no one customer have asked me to implement such functionality. Another usecase of dynamic groups is privilege escalation, i.e. executing some docbase commands with higher privileges. It is obvious that in complex project it is not possible (or very hard) to implement good security model, moreover, no matter how much you do try to implement security model – any new customer’s requirements can bring all your efforts to naught 😦

I know three options to implement privilege escalation in Documentum:

  • Manage superuser session in application, and use it, disadvantages:
    • Not transaction friendly
    • Sometimes insecure (see D2)
  • Code docbase methods, disadvantages:
    • Insecure (take a look at vulnerabilities in D2, that is because D2 actively uses docbase methods)
    • Not transaction friendly
    • Hard to design
    • Hard to refactor
    • Hard to maintain
  • Use dynamic group capabilities, disadvantages:
    • Not properly documented

Let’s remove white spot in documentation about dynamic groups!

Privileged groups

When designing model for dynamic groups, you can create your own set of groups and assign them to ACLs (as was previously “suggested” by EMC), but what to do with non-sysobject objects? For such purpose EMC designed a set of privileged groups. Documentation says following about this feature:

Installing Content Server installs a set of privileged groups. Members of privileged are allowed to perform privileged operations even though the members do not have the privileges as individuals. The privileged groups are divided into two sets.

and gives the following list of privileged groups:

group description
The first set of privileged groups are used in applications or for administration needs. With two exceptions, these privileged groups have no default members when they are created. You must populate the groups. The following table describes these groups.
dm_browse_all Members of this group can browse any cabinets and folders in the repository, folders except the rooms that were created using Documentum Collaborative Services (DCS). The dm_browse_all_dynamic is a member of this group by default.
dm_browse_all_dynamic This is a dynamic role group whose members can browse any object in the repository. The dm_browse_all_dynamic group is a member of the dm_browse_all group.
dm_escalated_allow_save_on_lock Used internally for RPS. Created and managed by superusers only. Members of this group can modify and save changes to an object that is checked out by other users.
dm_retention_managers Members of this group can:

  • Own retainer objects (representing retention policies)
  • Add and remove a retainer from any SysObject.
  • Add and remove content in a retained object
  • Change the containment in a retained virtual document

This is a non-dynamic group.

dm_retention_users Members of this group can add retainers (retention policies) to SysObjects. This is a non-dynamic group.
dm_superusers Members of this group are treated as superusers in the repository. The dm_superusers_dynamic group is a member of this group by default.
dm_superusers_dynamic A dynamic role group whose members are treated as superusers in the repository. The dm_superusers_dynamic group is a member of the dm_superusers group.
dm_sysadmin Members of this group are treated as users with system administrator user privileges.
dm_create_user Member of this group have Create User user privilege.
dm_create_type Member of this group have Create Type user privilege.
dm_create_group Member of this group have Create Group user privilege.
dm_create_cabinet Member of this group have Create Cabinet user privilege.
Following groups are mentioned in documentation as “internal”, i.e.: “The second set of privileged groups are privileged roles that are used internally by DFC. You cannot add or remove members from these groups.” So, description is written by me
dm_assume_user Not used
dm_datefield_override Not used
dm_escalated_delete Members of this group have DELETE_OBJECT extended permission for all sysobjects
dm_escalated_full_control Members of this group have all extended and DELETE permissions for all sysobjects
dm_escalated_owner_control Members of this group have CHANGE_OWNER extended permission for all sysobjects
dm_escalated_relate Members of this group have at least RELATE permissions for all sysobjects
dm_escalated_version Members of this group have at least VERSION permissions for all sysobjects
dm_escalated_write Members of this group have at least WRITE permissions for all sysobjects
dm_internal_attrib_override Not used
dm_user_identity_override Not used
Following groups are not mentioned in documentation, but CS creates them when installing
dm_assume_user_role Dynamic group for dm_assume_user
dm_create_table Not used
dm_datefield_override_role Dynamic group for dm_datefield_override
dm_delete_table Not used
dm_escalated_read Members of this group have at least READ permissions for all sysobjects
dm_internal_attrib_override_role Dynamic group for dm_internal_attrib_override
dm_read_all Members of this group have at least READ permissions for all sysobjects
dm_read_all_dynamic Dynamic group for dm_read_all
dm_workflow_task_supervisor Members of this group have the same permissions on workitems as workitem performer
dcs_privileged_users Another dynamic group for dm_superusers

As you can see the most powerful user in docbase is not a superuser, but superuser who is also a member of dm_escalated_full_control group. For example, D2 team does not know about this feature, so they are compelled to write some funny code like (see com.emc.common.dctm.utils.DfAdminSysObject, actually this class demonstrates that D2 team does know nothing about dynamic groups):

if (object.getPermit() < IDfACL.DF_PERMIT_WRITE) {
    object.grant(session.getLoginUserName(), IDfACL.DF_PERMIT_WRITE,
            null);
    object.saveLock();
}

Privileged groups could be completely disabled by enabling DISABLE_PRIV_GRPS module in dm_docbase_config, i.e.:

API> retrieve,c,dm_docbase_config
...
3c01ffd780000103
API> append,c,l,r_module_name
SET> DISABLE_PRIV_GRPS
...
OK
API> append,c,l,r_module_mode
SET> 1
...
OK
API> save,c,l
...
OK
API> reinit,c,
...
OK
API> ?,c,alter group dm_escalated_full_control add test01

API> connect,repo,test01,test01
...
s1
API> retrieve,c,dm_document where world_permit=2
...
0901ffd780026d39
API> get,c,l,_permit
...
2

4 thoughts on “Dynamic groups. Advances. Part II

  1. Pingback: CVE-2014-2507 consequences. Part II | Documentum in a (nuts)HELL
  2. Pingback: What is wrong in Documentum? Part I | Documentum in a (nuts)HELL
  3. Pingback: ACL computations | Documentum in a (nuts)HELL
  4. Pingback: JMS high availability feature | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s