Joshua Rogers and I were chatting, and talking about how easy it would be to make a malicious module which form_alter'd the modules page and kept itself from being disabled.

Also, thinking about how much of a pain it is to write code outside of full bootstrap (update.php, install.php, etc).

One solution we stumbled across is make a "core only mode". In this mode:

  • Only invocations for core modules would be allowed
  • No caches or registry business (so it can be used to fuel a way out of registry or menu cache hell).
  • No custom blocks (because these can contain user provided JS).

Does this sound like a reasonable way to provide a higher level of security on the pages you need to keep your installation secure and get critical information?

CommentFileSizeAuthor
#2 541444-2-add_bootstrap_core_phase.patch3.76 KBAnonymous (not verified)

Comments

Anonymous’s picture

Anonymous (not verified) commented

Subscribe

Anonymous’s picture

Anonymous (not verified) commented
Assigned: Unassigned »
Status: Active » Needs review
StatusFileSize
new 541444-2-add_bootstrap_core_phase.patch3.76 KB

Status: Needs review » Needs work

The last submitted patch failed testing.

sun.core’s picture

sun.core commented
Status: Needs work » Needs review
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Sorry. :\

axyjo’s picture

axyjo commented
Version: 7.x-dev » 8.x-dev

Looks like this is too late now. Deferred till D8.

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Status: Needs review » Needs work 
+++ includes/bootstrap.inc	6 Aug 2009 18:00:25 -0000
@@ -1507,8 +1514,12 @@
+    case DRUPAL_BOOTSTRAP_CORE:
+      require_once DRUPAL_ROOT . '/includes/common.inc';      ¶
+      _drupal_bootstrap_core();

trailing white space.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Issue summary: View changes
Status: Needs work » Closed (outdated)

Closing this issue as outdated. In Drupal 8 you can write your own module handler service now that could prevent certain hook invocations as Drupal contrib module. Feel free to reopen if you think this is still relevant for Drupal core.