[support] Locking down drupal for use by multiple (semi-)untrusted administrators

[Hugo Mills]

   I am part of a team of volunteers providing a hosting platform for
Linux User Groups in the UK. As part of this service, we are setting
up a "static and managed" (S&M) server, from which people can either
host static web content, or use pre-installed webapps which we
provide, such as MediaWiki. This will allow us to manage the software
versions, security patches and upgrades across all hosted sites,
without having to rely on the individual owners of the sites to
perform security upgrades in a timely fashion (which doesn't happen in
many cases).

   One requirement of this system, therefore, is that the users (i.e.
administrators of each website) don't have a direct login to the
machine, and that they can't run arbitrary code on it. This means that
we've made it impossible to execute PHP directly from their upload
space.

   In investigating fitting a multisite-mode Drupal into this
environment, I've found a few major issues for us so far, and would
appreciate any advice on how best to go about dealing with them in the
above environment.

1) Themes.

   From my limited investigation so far, it seems that Drupal themes
are basically PHP. Allowing users to upload themes directly is
therefore a no-no. Is there a non-executable type of theme that we can
support direct uploads for safely, or will all uploaded themes have to
be audited before we allow them up? How flexible would the system be
if we were to prevent theme uploads completely?

2) Input filters.

   In admin/settings/filters, there's a "PHP Code" filter, which seems
to give the option of allowing the administrator to execute arbitrary
PHP on the server. Is there any easy way of turning this off without
losing the filter module entirely? Are there any usability
implications of doing so?

3) Uploads.

   Is there adequate separation between sites' upload areas? I see in
admin/settings/file-system that there is a path for uploaded files.
What is there to prevent someone from pointing that path at another
site's upload directory and fiddling with their files?

4) What else have I forgotten or overlooked?

   The chances of having a malicious user are probably fairly small in
this set-up, but I'd like to keep it as "clean" as possible, so
pointing out any other glaring holes that would allow a site
administrator to execute arbitrary code on the server would be useful.

   Thanks for getting this far,
   Hugo.

-- 
=== Hugo Mills: hugo at ... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
       --- Never underestimate the bandwidth of a Volvo filled ---       
                           with backup tapes.                            
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.drupal.org/pipermail/support/attachments/20071120/17aace43/attachment.pgp