Security Around Setting Up a Sandbox

[Daniel F. Kudwien]

Reposting this from the consulting list to the proper list:

----------------------------------------------------------------------

Date: Mon, 2 Nov 2009 13:09:08 -0500
From: Shai Gluskin <shai@...>

Gang,

I'm real excited about Drupal 7. Just listened to the Lullabot podcast and
it's amazing how much has gotten in.

I want to help increase the number of people looking at D7 who don't have to
install it themselves in order to get more people:

   1. Finding bugs
   2. Finding UI issues
   3. Helping with documentation
   4. Getting excited about D7

I'm thinking of providing a sandbox on my server. I have found one other D7
sandbox at http://drupal7.socialconstruction.ca/. The D7 version at that
site was a month old. In addition, he wasn't letting people into
administration sections, just letting people create content. He said the
reason was "for security."

I had planned to give people a LOT more access than that. I certainly was
*not *going to give folks FTP or administer users permissions, but otherwise
I was thinking of giving authenticated users a lot of permissions. I'm
planning on having the Demonstration Site module
<http://drupal.org/project/demo>running to take snapshots on cron (and I
wouldn't give people admin privileges on that, obviously). So I could set
the site back if someone comes along and messes things up.

I'm not particular worried about cpu capacity or bandwidth. This sandbox
will not get a lot of traffic.

So the question is: is there a security concern that opening up such a
sandbox would endanger the client accounts I have set up on the same
dedicated server. The d7sandbox account would share an IP, a hard drive, and
the same server configuration with my client accounts, but nothing else. Is
there a danger with this? Would giving that account a dedicated IP make it
any safer? Other thoughts???
Thanks,

Shai

[Daniel F. Kudwien]

> I had planned to give people a LOT more access than that. I
> certainly was *not *going to give folks FTP or administer
> users permissions, but otherwise I was thinking of giving
> authenticated users a lot of permissions. I'm planning on
> having the Demonstration Site module
> <http://drupal.org/project/demo>running to take snapshots on
> cron (and I wouldn't give people admin privileges on that,
> obviously). So I could set the site back if someone comes
> along and messes things up.

Handing out administrative permissions needs careful thoughts.  In

Add Demo Secure module
http://drupal.org/node/375411

I outlined the critical steps to hand out _all_ administrative permissions
for the sake of my Total Admin IA Revamp proposal earlier this year, which
allowed to access and alter everything in Drupal.

That, of course, required additional steps.  However, if you skip the
following, then you should be fine:

:: WARNING: THIS LIST MAY NOT BE COMPLETE ::

- administer permissions: Prevents granting access to PHP permissions,
filter configuration.

- administer filters: Prevents access to filter configuration.

- administer languages: Prevents access to translation import functionality.

- administer demo site: Prevents access to Demo site administration.
(Attention: the "Reset" block can still be used, and can be enabled by
anyone who has "administer blocks" access.)


Additionally, I recommend to install a CAPTCHA or spam protection module.
If you want to grant access to "administer site configuration" (which
currently is the global access trigger for everything below admin/config),
then people will be able to enable/disable modules.  To prevent certain
modules from being disabled, you should put the following in their .info
files:

hidden = TRUE
required = TRUE


Please note that it's perfectly possible that some new functionality
(authorize?) could make all of this a bit harder.

sun

[T L-2]

Hi Shai-

That sounds really cool.  Just a few thoughts:

• I'd be concerned about allowing people to post any kind of content, in particular javascript or php.  So the first thing on my list to check would be the input filters that people are allowed to use.
• Besides that, maybe it would be helpful if you could list what permissions and admin functionality you are planning on enabling, so people could think about security with these features in mind.
• Lastly, since you explicitly asked, I can't personally recommend that you do this on a production server, but if you want to go down this route, I'd 1) try to setup some kind of apache jail for the d7 sandbox (this would separate the d7 system from the rest of your stuff) and 2) make sure that I had frequent off-site code and database backups for all of my client sites.

Again, cool idea.
Best,
tim

On Tue, Nov 3, 2009 at 9:46 AM, Daniel F. Kudwien <news@...> wrote:

> I had planned to give people a LOT more access than that. I
> certainly was *not *going to give folks FTP or administer
> users permissions, but otherwise I was thinking of giving
> authenticated users a lot of permissions. I'm planning on
> having the Demonstration Site module
> <http://drupal.org/project/demo>running to take snapshots on
> cron (and I wouldn't give people admin privileges on that,
> obviously). So I could set the site back if someone comes
> along and messes things up.

Handing out administrative permissions needs careful thoughts.  In

Add Demo Secure module
http://drupal.org/node/375411

I outlined the critical steps to hand out _all_ administrative permissions
for the sake of my Total Admin IA Revamp proposal earlier this year, which
allowed to access and alter everything in Drupal.

That, of course, required additional steps.  However, if you skip the
following, then you should be fine:

:: WARNING: THIS LIST MAY NOT BE COMPLETE ::

- administer permissions: Prevents granting access to PHP permissions,
filter configuration.

- administer filters: Prevents access to filter configuration.

- administer languages: Prevents access to translation import functionality.

- administer demo site: Prevents access to Demo site administration.
(Attention: the "Reset" block can still be used, and can be enabled by
anyone who has "administer blocks" access.)


Additionally, I recommend to install a CAPTCHA or spam protection module.
If you want to grant access to "administer site configuration" (which
currently is the global access trigger for everything below admin/config),
then people will be able to enable/disable modules.  To prevent certain
modules from being disabled, you should put the following in their .info
files:

hidden = TRUE
required = TRUE


Please note that it's perfectly possible that some new functionality
(authorize?) could make all of this a bit harder.

sun

--
Tim Loudon

[Andrew Berry-3]

On 2009-11-03, at 9:20 AM, Daniel F. Kudwien wrote:

> The d7sandbox account would share an IP, a hard drive, and
> the same server configuration with my client accounts, but nothing  
> else. Is
> there a danger with this?

It depends on how you have PHP set up. If it's php-cgi with suphp, you  
don't have too much to worry about. mod_php or similar, and everything  
is running under the same user account opening up greater  
possibilities of exploiting your customer's sites.

It sounds like you have a dedicated server. If it's got the resources,  
why not install VirtualBox or set up KVM? Then, you could not only  
snapshot the Drupal install, but the whole server setup. You could  
even go the extra step of making the appliance available for anyone to  
download :)

--Andrew