Hello all,
This is a general question.
To be able to install plugins from the OJS administrative interface, the plugins folder has to be writeable by the web server. This could pose a security risk.
A possible mitigation could be:
- chown the plugins directory to the web server user;
- install/update plugins;
- chown the plugins directory back to another user (e.g. root)
Do people have any advice here? Is the above a good idea, or could I just as well leave the plugins directory permanently owned by the web server user?
Thanks in advance,
Jan Pieter Kunst
Application Version - e.g., OJS 3.1.2:
OJS 3.3.0.7
Hi @huc-di-infra,
It sounds like you’re describing a mod_php environment or similar (where all PHP scripts run as the web server user, i.e. www-data or apache or similar). In this case, it’s not just the plugin installation directory that poses a potential problem – it’s also the files directory and the cache directory. On a shared host with other accounts running PHP scripts, these will all be vulnerable to access by other users.
Instead, we recommend using some kind of setuid environment where PHP scripts run under your own user account. This can be provided via FPM, CGI, or FastCGI environments. Commercial service providers tend to use environments like these.
Regards,
Alec Smecher
Public Knowledge Project Team
The host in question is not in a shared hosting environment, so there is no danger of other users on the system getting access to files.
The danger (but I’m not sure how serious this danger actually is) would be external bad actors getting write access to parts of the webroot through leaks in software served by apache (in this case, OJS or its plugins).
If I understand things correctly, having PHP scripts run by a user account instead of the web server user would not help here, if the files in the webroot are owned by that user account. It looks to me like the attack surface would even be greater, because the whole webroot would be writeable for PHP scripts served by apache, and not just files/cache/plugins.
Hi @huc-di-infra,
If you run your PHP scripts in a setuid environment, it’s possible to partition the server so that e.g. only a single installation of OJS runs under a particular user account (if you like). Thus yes, if someone is able to maliciously gain write access to arbitrary files under that account, it could be possible to create content in certain directories and execute it as PHP code by constructing URLs to it.
For this reason we are careful not to allow arbitrary path construction in anything that writes files!
Using chown to temporarily grant and then restrict write access to the plugins directory is not a bad idea, but it doesn’t address other directories where similar things might happen – cache and public are the leading contenders. (The files_dir configured in config.inc.php should already be outside the web root.)
If you want to further mitigate this risk I would recommend working with your web server configuration to prevent script execution entirely in cache, plugins, and public. While plugins does contain PHP code, this code is always included via PHP’s require or include functions, rather than being executed directly.
If you’re interested in something more structural, there is some discussion here: Change web root from application root directory for security · Issue #1832 · pkp/pkp-lib · GitHub
However, many of our users run in shared hosting environments without much opportunity to reorganize the hosting, and this would likely be catastrophic for them.
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you @asmecher , preventing script execution in cache/plugins/public sounds like a good strategy. I will look into it.
Having the plugins directory writeable by the web server would be more user friendly for our OJS admin (I’m the sysadmin, not the OJS admin) because they would not need me to change permissions.
A writeable plugins directory in which no script execution is possible seems like an acceptable middle ground between safety and user-friendliness.
Thanks for the insights!
Regards,
Jan Pieter Kunst
1 Like
This topic was automatically closed after 4 days. New replies are no longer allowed.