Run file operations under sudo [#2378175]

By far, the most common errors I see are caused by messed up file permissions. This can be caused by any number of things, including a site simply writing into a site's files directory with mode 600.

We currently use PHP functions (chgrp(), chmod() and chown()), which limits us to the aegir user's rights. I usually have to run some chmod's, chown's and/or chgrp's on the cli as root to fix such things.

I think we should consider giving the aegir user sudo access to these commands. Among other things, this would entail making system calls, rather than using PHP's functions.

Comments

Comment #1

mvc

they

English

Montréal, CA

CreditAttribution: mvc commented 20 November 2014 at 14:26

Hmm. How about writing a separate shell script which runs these commands, and letting the aegir user run just that as sudo, as is currently done for apachectl? This would help minimize the damage if a site is hacked in a way that inserts code which runs as aegir.

Comment #2

omega8cc CreditAttribution: omega8cc commented 20 November 2014 at 16:27

This is an invite to privileges escalation vulnerability and will degrade security seriously. We already have enough serious issues still to fix in this area and adding yet another potential backdoor is not a good idea, IMHO. In BOA we are using external maintenance script to fix various permissions issues but without adding more power to the Aegir backend user.

Also, in BOA we have already restricted the access to almost all binaries, so Aegir backend user couldn't run not whitelisted commands via system calls directly anyway. It must be forced to use PHP functions, so various restrictions we have already put in place in BOA, including shell wrappers, blocking uploaded shells etc, despite Drush official requirement, which we have silenced in our Drush fork with improved security, could still work.

The problem is real, but expanding Aegir backend user privileges is not the right way to fix this, I think.

Comment #3

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

CreditAttribution: ergonlogic commented 30 November 2014 at 20:38

I agree that direct sudo access to chmod and such is a bad idea. However, wrapper scripts can be made secure, as @mvc suggests.

We already have enough serious issues still to fix in this area and adding yet another potential backdoor is not a good idea, IMHO.

@omega8cc, can you provide pointers to the issues you're referring to? I don't see anything related on security.drupal.org.

Comment #4

omega8cc CreditAttribution: omega8cc commented 30 November 2014 at 20:59

I referred to this old issue: https://www.drupal.org/node/762138#comment-8711115

Even with a wrapper used, it will be still possible to trick Provision into using malicious binaries or access otherwise restricted parts of the filesystem, unless you will use absolute paths to all binaries there and not rely on a PATH.

We are using a wrapper which replaces system symlink /bin/sh in BOA, so we can still detect and deny attempts to use uploaded binaries to circumvent restrictions set via binaries ownership/group/permissions, plus paths checks and with open_basedir and disable_functions, but outside of BOA it is just too dangerous, IMO. It is just too easy to trick Provision into doing very nasty things if we will open this further than it's open already.

And once you allow to use system calls directly, outside of PHP open_basedir and disable_functions boundaries, just with exec(), you have already announced a 'hacked!' party.

Comment #5

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

CreditAttribution: ergonlogic commented 30 November 2014 at 22:24

First off, these wouldn't be Drush scripts, for exactly the reasons mentioned in that issue; we can't sufficiently control the code being bootstrapped. Calling them with an absolute path shouldn't be too hard, since they'd presumably live under the provision directory, which itself shouldn't be owned by the 'aegir' user. We could then use open_basedir to restrict these scripts to something reasonably safe like /var/aegir/platforms. A simple .ini file (at /etc/aegir.ini maybe) could specify basedir, owner, group and permissions combinations.