Server security needs to be hardened

Would like to know how we'll solve it, as Demo module tries to achieve something similar.

+1 for OpenVZ. That's the only possible solution.

This said, I'm still -1 on this general idea. Too much a hassle, too many security concerns, too many people that actually care about it, too few benefits.

You can do that, but then the problem is if someone's trying to test a bug related to drupal_eval(), they can't. However, that's a pretty extreme edge case. ;)

However, database credentials still apply, since you can't effectively lock down those without crippling the demo site.

We discussed this in detail with dww and cyberswat and as has been stated before security is something we cannot really enforce well. Just as with the patch testing clients anyway can demo any patch. Thus they could upload a patch that just hardwires Drupal to do something bad or just upload their own php evalutating module.

We just need to have the AMI re-installed every 24 hours and as we have already confirmed mail sending is not installed. The usefulness of the box outside of that is limited as a bot or what not if possible.

After a lengthy discussion we decided we had done all that made sense. Unless anyone has an good ideas I think we have done all we can, except possibly chx's thought, but I am not exactly sure what he is reffering to.

Jacob: If my understanding of the problem is correct (which is somewhat unlikely at 4am,) one possible scenario is that two people start new demo sites around the same time. If the first person attempts creating a new account with their day to day password (yes, I realize that is HIGHLY unwise,) there could be a problem. All that would be required is for the second site to grab the {users} table from all available sites and they would have the hashed form of the user's password.

Taking this a little further, another possibility would be that site B rewrites the {system} table of all other available databases so that "modules/user/user.module" is replaced by "../notthedroids/modules/user/user.module". Suddenly, the password hashing algorithm used on all demo sites is $hashed = $prehashed;

I suspect that this feature would be most used by people who do not know how to patch an installation themselves. Because of this, I also suspect that they would be more easily lulled into a very false sense of safety "since my site (and data) will be removed later anyway."

OpenVZ does seem like the best solution. Second to it would be a something like suPHP. Either way, I'd hope to see a new database user (with very limited permissions) created for each installation.

(While we're suspecting malicious users though, I wonder how long it will take for someone to post / try a "patch" that completely replaces the Drupal file tree with WordPress... Either that or just changing $databases to something that is hosted somewhere else.)

There is absolutely no point in removing drupal_eval(), because the whole point of the testing site is *to test a patch*, so code injection is already possible *by nature*.

This whole project is a no-go, supposing that the module doesn't support spawning each demo site in a separate OS-level container (OpenVZ-type). I'll not run any demo server that doesn't support this.

I don't think restricting projects to official releases solves the concerns voiced by Damien in #11. As he mentions, regardless of how stable the release the patch is being applied against is, the patch could simply revert security checks added in the stable release (accidentally or on purpose), or someone could just upload a patch that deleted the entirety of Drupal core and replaced it with code for a rootkit. :P We'd of course catch a blatant attempt to be a complete ass eventually, but maybe not until they'd wreaked some serious havoc.

Anyone with familiarity with OpenVZ know how much effort we're talking about here? Is it kind of "install and go", or will it require a bunch of work on the PIF[R|T] side to integrate..?

Oh. :(

Could we still do the "Download this patch + project together" on testbot results?

Modifying the code to provide a download link of the code and not an instance isn't to difficult but if we go that route wouldn't it make more sense to just apply the patch in your own sandbox and not have to support this at all?

No, this would still be a huge win. In order to even use the patch command, you need special tools on Mac and Windows (which probably covers at least 80% of our users) that 99% of them don't have unless they go way out of their way to put them there. This would open up patch testing to thousands of others; if they already know how to download core and modules, they'd be able to help test patches (albeit not as optimally, as they'd need to go through the install each time).

I understand the concern about further resource utilization, and the burden this places on test client providers. At this point I'm a bit out of my depth to know whether the security/resource trade-off is an acceptable one.

I think we'd just re-use whatever the packaging scripts are doing for install profiles. Which, afaik, is on the fly.

my 2¢...

• Set session.cookie_path so that cookies are restricted to the particular demo instance (when we chatted at DCSF Jimmy indicated each instance would share an IP with many others, but be in a unique subdir).
• I know outgoing connections will be blocked, but can INCOMING connections be restricted to the IP that created the demo instance? This would prevent the demos being used a a host for other malware.
• Can disk and DB quotas be used to prevent one demo from filling the disk?
• Quotas on CPU, to prevent someone from stealing cycles for hard computations (like password cracking)?
• A good IDS sounds worthwhile, because it might be able to catch things we haven't thought of yet.

+1 on enabling this for themes too. Also +1 on not giving up, this has awesome potential.