Paranoia

A security module that protects Drupal sites from insecure configurations by disabling dangerous modules, hiding risky permissions, and preventing arbitrary PHP code execution.

paranoia
1,534 sites
42
drupal.org

Overview

Paranoia is a defensive security module designed for system administrators who want to prevent CMS administrators from executing arbitrary PHP code. The module implements multiple layers of protection to reduce security risks associated with PHP execution capabilities in Drupal.

The module automatically disables the PHP module when installed, hides dangerous permissions from the permissions administration form, and prevents any role from being elevated to admin status. It also protects the user/1 superuser account from being modified by other administrators, ensuring that only the superuser can change their own credentials.

Paranoia provides an extensible hook system that allows other modules to declare additional modules to disable, permissions to hide, routes to block, and forms to disable. This makes it a flexible security framework that can be adapted to specific site security requirements.

Features

  • Automatically disables the PHP module and skinr_ui module upon installation
  • Hides 'use PHP for settings' and 'use text format php_code' permissions from the permissions form
  • Prevents granting 'restrict access' marked permissions to Anonymous and Authenticated roles
  • Blocks risky permissions from contrib modules including devel, googleanalytics, bueditor, auto_username, and auto_entitylabel
  • Removes the admin role property from all roles and prevents any role from being elevated to admin status
  • Hides Paranoia, PHP, and other disabled modules from the module administration pages
  • Protects user/1 account - only user/1 can modify their own name, email, and password
  • Blocks access to dangerous routes like devel.execute_php
  • Disables risky forms that could enable Remote Code Execution (RCE)
  • Provides extensible hook system for custom security configurations
  • Reports PHP module status in site requirements check
  • Cannot be uninstalled through the admin UI by design - requires drush or database manipulation

Use Cases

Hardening a Multi-Admin Site

On sites with multiple administrators, Paranoia prevents any admin from gaining elevated privileges or executing arbitrary PHP code. Install Paranoia to ensure that even trusted administrators cannot accidentally or intentionally compromise site security through PHP execution capabilities.

Compliance and Security Auditing

Organizations requiring security compliance can use Paranoia to automatically enforce security policies. The module ensures that dangerous permissions cannot be granted through the UI, providing an additional layer of protection that satisfies security audit requirements.

Protecting Against Compromised Admin Accounts

If an administrator account is compromised, Paranoia limits the damage an attacker can do. They cannot enable the PHP module, execute arbitrary code, or modify the superuser account, significantly reducing the attack surface.

Preventing Accidental Security Misconfigurations

Site builders may not be aware of the security implications of certain permissions. Paranoia automatically hides these dangerous permissions, preventing accidental grants that could expose the site to code execution vulnerabilities.

Locking Down Development Modules in Production

When devel module is accidentally left enabled in production, Paranoia blocks access to dangerous routes like devel.execute_php and disables the PHP execution form, preventing potential Remote Code Execution vulnerabilities.

Extending Security Policies with Custom Modules

Developers can create custom modules that implement Paranoia's hooks to add site-specific security restrictions. For example, hiding proprietary internal modules from the admin interface or blocking access to sensitive custom routes.

Tips

  • Install Paranoia early in the site development process to establish security baselines before other administrators begin work
  • Use Paranoia's hooks in custom modules to extend security policies specific to your organization
  • Remember that Paranoia cannot be uninstalled through the UI - plan for this when deploying to production
  • Check the site status report regularly for warnings about the PHP module being enabled
  • Combine Paranoia with other security modules like Security Kit (seckit) for comprehensive protection
  • When developing custom modules, use hook_paranoia_hide_permissions() to hide sensitive permissions you define

Technical Details

Hooks 5
hook_paranoia_disable_modules

Declares modules that should be automatically uninstalled. When the module admin form is submitted, any enabled modules in this list will be uninstalled.

hook_paranoia_hide_modules

Declares modules that should be hidden from the module administration pages. Hidden modules will not appear in the module list or uninstall forms.

hook_paranoia_hide_permissions

Declares permissions that should be completely hidden from the permissions administration form. These permissions will be automatically revoked from all roles.

hook_paranoia_hide_routes

Declares route names that should have their access denied. The RouteSubscriber will set _access requirement to FALSE for these routes.

hook_paranoia_risky_forms

Declares form IDs that should be disabled for security reasons. These forms will have #access set to FALSE and a validation that always fails.

Troubleshooting 6
Cannot uninstall Paranoia through the admin UI

This is by design. Paranoia hides itself from the module administration pages. To uninstall, use drush: 'drush pm-uninstall paranoia', or delete the module directory from the filesystem and clear caches.

PHP module status error appears in site status report

The PHP module has been enabled directly in the database, bypassing Paranoia's protection. Disable the PHP module using drush: 'drush pm-uninstall php', or directly update the database to remove it.

Cannot grant certain permissions to roles

Paranoia hides dangerous permissions from the permissions form. This is intentional security behavior. If you need to grant these permissions, you must first uninstall Paranoia.

Cannot set a role as admin role

Paranoia prevents any role from having the admin property set to TRUE. The module blocks this in hook_user_role_presave and hides the admin role selector from user settings.

Cannot edit user/1 account details

Paranoia restricts modification of user/1 credentials to user/1 themselves. Log in as user/1 to make changes to the superuser account name, email, or password.

Certain modules keep getting disabled

Paranoia automatically uninstalls modules declared in hook_paranoia_disable_modules(). By default, this includes php and skinr_ui. Check if custom modules have added to this list.

Security Notes 6
  • Paranoia is a defensive module that reduces attack surface but should not be considered a complete security solution
  • The module protects against UI-based attacks but direct database manipulation can bypass protections
  • Always keep Drupal core and contributed modules updated for comprehensive security
  • Monitor the paranoia log channel for alerts about blocked admin role elevation attempts
  • The delete_blocked_users configuration option should be reviewed for your specific security requirements
  • Consider that hiding modules and permissions from the UI does not prevent programmatic access - additional code-level protections may be needed