> Since Airship self-updates, it needs to be able to write to itself.
> chown -R myusername:www-data airship
> chmod -R g+w airship
Have you ever wondered why some people say that PHP is insecure? That's one of the major reasons.
This app claims to care about security, but at the same time it self-updates and has no external code integrity control. This means that if the webapp has a vulnerability which was exploited, it will be very hard to detect it -- was this file changed by auto-updater or by malware? you don't know. And even if the new version of webapp was released which fixes the bug, you can not be sure that infection is gone -- because the update process may also be compromised. And you cannot easily remove code dir and re-download -- the settings are mixed-in with the code.
Compare it with any other stack -- Ruby on Rails, Django, JAR files, whatever. Code cannot modify itself. The only writable thing is the database. Additionally, the repository is often under git control. If there is a vulnerability, update software and restart the server (if in doubt, backup the database and nuke/rebuild the server instead). Even if you made a configuration error and left code dir writable, "git status" is enough to tell you any changed/added files.
And this is why you, as an admin, should avoid PHP if you care about security. Sure, you can use sane techniques even with PHP code -- I am sure that's what Facebook and Wikipedia do -- but most random PHP projects will require writable code dir. When choosing a web app, choose non-PHP one first.
It also convers the "external code integrity control":
Keyggdrasil makes sure everyone sees the same public keys, prevents anyone from rewriting history, and makes targeted attacks noisy.
Autoupdating is not a feature specific to PHP. You can do manual updates as you described with it too, so I'm not sure why you even contrast it to other languages or CMS.
It's pretty much established that properly implemented autoupdates increase security, not reduce it. I agree that writeable and executable directory is a huge risk, though.
Security at the expense of usability, comes at the expense of security.
CMS Airship went with the "self-writing code" option because we believe the potential damage of a 1day vulnerability to be much a higher concern than theoretical "this isn't really following best practices grumble grumble".
By all means, don't chmod/chown anything, and run continuum.sh as a more privileged user if that's what you want.
I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect.
Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update. And obviously, the first thing attacker would do will be to disable any integrity checks your auto-update does. So in the most common case, the host will stay compromised forever.
This looks pretty horrible to me. I am appealed that you call this "theoretical". But then, (in my experience) the security is not a strong side of PHP community.
The sad part, it is not hard to fix. You already have separate update script -- obviously "don't chmod/chown anything" is not enough, you at least want the cache directory to be writeable, and while I have not looked at the code, I suspect there may be other locations that web app will want to write to. You can change your Dockerfile to use secure setup. It will take a bit of work but it is definitely possible.
Until this is done, "simply secure" is only until the first compromise.
> I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect.
The auto-updater does nothing to make this worse. That's true of any vulnerable system. Once you're owned, you're owned.
> Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update.
It runs every 15 minutes, in the default configuration, and our usual turnaround time for getting a bugfix out is less than 1 hour.
> The sad part, it is not hard to fix.
It's not broken, it's a trade-off. Nothing to fix.
> You already have separate update script
That's the kicker: If your threat model prioritizes "don't let the httpd write to the web directory" higher than your usual non-power-user, then simply:
1. Set up a cronjob to run the update script, run by a more privileged user.
2. Don't chown/chmod.
The reason we do this by default is because our threat model is ensuring automatic updates work for everyone (including people who are not sophisticated enough to set up a cronjob).
> You can change your Dockerfile to use secure setup. It will take a bit of work but it is definitely possible.
I guess?
The Dockerfile was provided by the community and is maintained by the community; I don't use it nor do I touch it.
> The auto-updater does nothing to make this worse. That's true of any vulnerable system. Once you're owned, you're owned.
No. If you have RCE in the regular app, the attacker cannot make attack 'stick'. Once you reboot the machine, or restart service (in case of systemd), any malicious code no longer runs.
Now, if there is a privilege escalation bug the situation will get worse, but having 2 unpatched bugs is significantly less likely. Of course, you want to make sure unattended updates are enabled so your host OS is up to date.
As a result, most other systems will actually self-heal from minor compromises. Only your system (any many other PHP systems in general) will stay compromised forever.
> It runs every 15 minutes, in the default configuration, and our usual turnaround time for getting a bugfix out is less than 1 hour.
1 hour from what? From someone sending email to your team? If a black hat finds an exploit in your service, they will start compromizing the existing web servers first. You will not find out about the bug until someone notices something weird on their installation, and that will take way more than an hour.
> 2. Don't chown/chmod.
Have you actually tried this? Looking at your github, there seems to be `src/tmp/cache` directory -- presumably at least this one should be chmod'ed? What about others? What about plugins -- would they work fine without writeable root?
I have tried to make other PHP packages use immutable code, and it was very flaky and painful. You need to structure your program in a certain way to make sure it works with immutable root -- one location for temp, another for configs, third for the code. If your main development team uses writable code, there is a high chance immutable code would not work well.
> It's not broken, it's a trade-off. Nothing to fix.
> The reason we do this by default is because our threat model is ensuring automatic updates work for everyone (including people who are not sophisticated enough to set up a cronjob).
Why do you say it's hard to set up a cronjob? It is simple -- your deb/rpm package just includes file /etc/cron.d/aristrip, and voila -- you are done. The only place where cronjob setup is hard is on these cheap shared PHP hosting services. And I think no one should be using them -- get a $5 Linode VM instead.
The thing is, the modern Linux systems went pretty far in terms of security and isolation. You have multiple easy-to-use technologies for threat protection -- docker, Apparmor, capabilities, systemd' *Path, etc.. They work pretty well to make sure that attacker which got RCE cannot take a hold on a system and elevate privileges.
Except your system is not compatible with any of them, by design. Because you don't care. Maybe you should change your motto from "A Secure Content Management System for the Modern Web" to "A Secure Content Management System for the Cheap Shared PHP Hosting", because you can certainly do much better for the modern web.
> chown -R myusername:www-data airship
> chmod -R g+w airship
Have you ever wondered why some people say that PHP is insecure? That's one of the major reasons.
This app claims to care about security, but at the same time it self-updates and has no external code integrity control. This means that if the webapp has a vulnerability which was exploited, it will be very hard to detect it -- was this file changed by auto-updater or by malware? you don't know. And even if the new version of webapp was released which fixes the bug, you can not be sure that infection is gone -- because the update process may also be compromised. And you cannot easily remove code dir and re-download -- the settings are mixed-in with the code.
Compare it with any other stack -- Ruby on Rails, Django, JAR files, whatever. Code cannot modify itself. The only writable thing is the database. Additionally, the repository is often under git control. If there is a vulnerability, update software and restart the server (if in doubt, backup the database and nuke/rebuild the server instead). Even if you made a configuration error and left code dir writable, "git status" is enough to tell you any changed/added files.
And this is why you, as an admin, should avoid PHP if you care about security. Sure, you can use sane techniques even with PHP code -- I am sure that's what Facebook and Wikipedia do -- but most random PHP projects will require writable code dir. When choosing a web app, choose non-PHP one first.