In IRC we were brainstorming about security updates and how drastic we should be when we find them. Boris suggested that if we find a missing security update, we should put the site into maintenance mode (ala admin/settings/site-maintenance) and email UID 1. ;)
That's actually a pretty good idea. It'd require a little effort, since we'd want to split up UPDATE_STATUS_NOT_CURRENT and have a separate value, UPDATE_STATUS_NOT_SECURE. That's probably worth doing for other reasons. But, in hook_requirements(), if we saw that, and our setting were set to true, we'd put the site into maintenance mode. Should be relatively easy, and probably a nice touch to help security.
That said, I'd probably make this setting default to off. ;)
Comments
Comment #1
boris mann commentedI actually think we could have this toggle be "on" by default.
dww should mention that we also considered workflow whereby contrib modules that want to do a security release are moderated by default, and the security team reviews them before release.
I'm +1 for the concept, although I do think update_status should remain a separate module so it can be completely disabled for alternate hosting / support concepts.
Comment #2
dwwSee http://drupal.org/node/153973 about a moderated workflow for security update release nodes on d.o.
Comment #3
alpritt commentedRather than putting it into a specific mode, would it be better to tie it to actions? That way I'd have the choice of how it reacts.
Some example choices:
* Put site into maintenance mode.
* Disable comments or new posts, but site is still online
* Send me an email, or text message or whatever
* Disable new user sign ups.
* Disable entry for existing users
Few people are going to want the extreme of a complete lock-down, but some people may want to disable comments or any other likely security holes. Many, many people would just love an email or a text message.
Comment #4
Frando commented+1 to Actions integration!
This sounds simply perfect, given the actions patch lands ;) and given that the required actions will be in place.
Otherwise I'd vote for the setting, disabled by default.
Comment #5
Frando commented+1 to Actions integration!
This sounds simply perfect, given the actions patch lands ;) and given that the required actions will be in place.
Otherwise I'd vote for the setting, disabled by default.
Comment #6
kbahey commentedPutting the site in maintenance mode is another way of saying "Hackers! I am running an insecure version of Drupal! Hack me!" Well, they will not be able to log in, but some vulns may be exploitable by other means.
-1 for anything draconian like that.
+1 on things like:
- Sending a daily email to the admin.
- Putting a drupal_set_message() for anyone logged in with a user_access('administer site') on every page.
Comment #7
kbahey commentedAlso good to have a watchdog hook message with high level (alert, critical) as well. Sites may have that redirect to syslog, email or SMS and hence maybe notified to a pager or Blackberry.
Comment #8
dwwwatchdog() won't do at all, since there are no ACLs on who can see the messages. :( Everything can be seen with just 'access administration pages', yet we don't necessarily want everyone with that perm to know the site is insecure. :( See http://drupal.org/node/124715 for more on this.
#124715 added simple email notification, and that's probably good enough for 5.x-2.0, along with the status report, modules page, etc.
A separate setting for site maintanence mode is silly, I agree. Integration with actions is the way to go. However, I definitely don't have time to mess with contrib actions for D5, and core actions for D6 hasn't landed yet, either. So, I'm not going to worry about this anymore. I'm worried enough about getting this done before the freeze as it is, I don't want to tie myself to another unknown...
Comment #9
kbahey commentedI would assume that everyone you give access administration pages is trusted in the first place. They are given this to do their work, not to be curious, so they can act on this, if only to call you on the phone or something.
What I meant was you log a watchdog message using a high level (e.g. CRITICAL). Then if the site admin wants this to go to someone's pager, or email, then they can do that using the emaillogging module.
It also lets people who use syslog forward that to their networking monitoring system and they can act on it anyway they like.
It is a one liner really.
Agreed. As always, code can be refined later, features can be refined later.
+ for actions. So if someone wants the disks to be formatted, they can do that.
Comment #10
flickerfly commentedIf it get's stuck in off-line mode by default, then we need to be sure that off-line mode's message makes clear what the reason for it is. I like the idea that this would be done for lackadaisical admins, but I also fear these same admins would spend hours trying to figure out what's going and and then be very interested in dumping drupal for a policy that caused such a headache. Then we'd have another reason to be seen as 'non-user friendly'.
The result, of course, is an alarm to all the web that this site is insecure. Can a site be access outside the /user page when the site is in this mode? Meaning can you attack the site if the issue isn't relate to the login form?
Comment #11
dwwI'm not adding new features to the D5 contrib version of update_status. Anyone who's interested in this should work on #158541: Integrate update.module with actions.module, instead.