This project is not covered by Drupal’s security advisory policy.
Motivation
Drupal has two extremely powerful permissions:
- Administer permissions allows assigning all permissions to any role, even to the anonymous user role! Specifically, a user with this permissions can obtain any other permission for himself.
- Administer users allows editing any user, including his own and even user 1. This includes
- assigning/removing any roles (and thus any permissions),
- changing the user's name (to cover his tracks),
- changing the user's password (to downright hijack an account), or
- changing the email address (to obtain a log-in link to gain access to the other user's powers without his knowledge).
- It also allows deleting any user, including user 1, which can seriously disrupt the site's operation.
This means that either of these permissions allows obtaining complete control over your site, and you as site administrator or consultant may be reluctant to give a role with either of these permissions to someone else, because
- you may not trust their Drupal competence,
- you may not trust their integrity, and/or
- you may not trust their ability to keep their account safe from others.
However, as long as you withhold these permissions, you will never have an assistant or successor who can learn how to do your job. It becomes obvious that we need safe versions of these permissions that we can grant to others without putting the entire site at stake, in order to get help managing normal users and to introduce our assistants to using the permissions page by giving them a safe subset.
This module provides an install-it-and-forget-it solution that is in many ways superior to solutions that require you to define and continually audit (think about that!) and maintain explicitly who can do what.
No Endorsement
The Drupal Security Team does not provide endorsements for contrib modules. Their stand is that it's the site administrator's job to safe-guard the Administer permissions and Administer users permissions, and that a site where either of these permissions is compromised is a broken site.
As with all contrib modules, especially those that relate to security, you can rely on the community for testing and feedback, but ultimately, you yourself are responsible for determining whether it meets your requirements.
How It Works
The Protect Permissions (PP) module automatically protects all the security-relevant permissions using the following rules:
- PP sanitizes the Administer users permission for users who have Administer users but not Administer permissions ("deputy admins"). Users without the former pose no risk, and users with the latter are all-powerful anyway.
- PP considers only permissions that are marked as having security implications, in core or contrib.
- Deputy admins cannot assign or remove roles that carry security-relevant permissions, which they don't hold themselves.
- In addition, deputy admins cannot edit user names, email addresses, nor passwords of accounts that hold security-relevant permissions, which they don't have themselves, nor can they cancel/block/unblock any such accounts (directly or through bulk operations). This ensures that deputy admins (or someone who stole such an account) cannot obtain additional permissions or disrupt the operation of a site through hacking.
That's the basic PP functionality. It automatically takes the security and manageability of your site to a new level simply by installing PP. The following items provide additional related goodies:
- The new Administer user settings permission governs access to the
admin/config/people/accountspages. Access to these pages is not required for daily operation.One setting on the
admin/config/people/accounts/settingspage, the Administrator role selection, carries a much higher security risk than all the others. We think this selection should be restricted to the Administer permissions permission, and we consider this to be a bug in D7. The Fix Core module for D7 has a fix for this. - The optional new Administer safe permissions permission allows you to grant selected deputy admins access to a sanitized permissions page (with all permissions grayed out that have security implications), so that they can add or remove non-security-relevant permissions to/from any role and learn how use that page.
- The optional new Administer own permissions permission works like the Administer safe permissions, but it makes a different subset of permissions available: those that the user himself holds, including the (restricted) Administer users permission, but excluding the two new Administer xyz permissions permissions.
- Either of the last two permissions allows creating and deleting roles, as long as these roles do not carry inaccessible permissions. They can be granted separately or together.
- The PP module protects itself against being disabled by anyone but user 1 and users holding the core administrator role.
Installation
- Copy the entire
protect_permissionsdirectory, containing theprotect_permissions.moduleand other files, to your Drupal contrib modules directory. Do the same for the required Chain Menu Access API module. - Log in as site administrator.
- Go to the module administration page and enable the module.
Configuration
There is no configuration necessary. If you want, you can assign the new sanitized
- Administer user settings,
- Administer safe permissions, and
- Administer own permissions
permissions.
Development progress
This module is in initial development. You are invited to comment on the design outlined above in the issues queue.
Seeking co-maintainer(s)
Unfortunately, we have not been able to dedicate sufficient time so far to make this fly. Please get in touch if you're interested in working on it for D7 and/or D8.
Project information
Seeking co-maintainer(s)
Maintainers are looking for help reviewing issues.14 sites report using this module
- Created by salvis on , updated
This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.
