This is a cross-post and slight edit of a portion of a post I made in the Usability group concerning my reactions as a Drupal pre-install newbie over the course of the recent Bay Area Drupal camp (BADCamp). This does not concern any specific Drupal vulnerability as I don't know of any vulnerability or even if what follows is accurate. It is just a result of seeing various published Drupal security reports and putting that together which what I saw at BADCamp plus some thoughts of my own. I have not looked at Drupal source code.
As a webmaster who wears many hats I am concerned with website security (and minimizing the time I need to spend on it). One of the things I am concerned about is module security. What Drupal can do to assist me is to have redundant security. Of course all modules and Drupal must protect against SQL injection. But -
Does Drupal control content access not only though the Drupal authority tables but also redundantly through MySQL's mysql table? That is, ideally Drupal would be divided into multiple databases:
* content data
* configuration data
* theme data
* authorization data
* visitor contributions data
* sensitive visitor data (e.g. e-mails, phone numbers, other personal private info)
Only the webmaster (User 0?) and their backup IT staff would have update authority to authorization data as controlled by both Drupal and the mysql database. This group would have at least one mysql user name, but preferably one mysql user name per Drupal user.
Only IT and design staff would have update authority for configuration and theme data as controlled by both Drupal and the mysql database. This group would have at least one mysql user name different from the webmaster's mysql user name, but preferably one mysql user name per Drupal user.
Only other authorized staff would have update authority for content data as controlled by both Drupal and the mysql database. This group would have at least one mysql user name different from both the webmaster's and the IT/design staff's mysql user names, but preferably one mysql user name per Drupal user.
If the website also allows visitor contributions, this to would be controlled by both Drupal and the mysql database. This could be a single mysql user, but mysql must give it update authority only on the user contributions database.
For that matter, since Drupal must store the various MySQL passwords (hopefully encrypted), the MySQL table containg user 0's MySQL password must not be readable (as defined by the MySQL mysql database, not just by Drupal) by any other Drupal user.
So if a module failed in security, the rogue website visitor still wouldn't be able to do any damage, as Drupal would be using a different mysql user name to access the various databases, a user name that did not have read authority.
If a staff member other than the webmaster or their assistants tried to do something only the webmaster had authority to do, even if there was a bug in Drupal or a module it wouldn't matter because MySQL itself would disallow updating of the administration database for that user.
This would seem to be a security issue and not a usability issue, but whatever time I have to spend in security is time I cannot spend posting content or improving the customer experience. So, setting up security for redundant protection becomes a usability issue for me.
Comments
I've heard of systems like
I've heard of systems like this in use. I've never actually seen one :)
I think it's theoretically a nice architecture. There are probably ways to do something like this in a highly-customized web application built on top of Drupal by using the db_set_active command.
If you do build something like this, be sure to come back and talk about whether it worked well for you :)
knaddison blog | Morris Animal Foundation