> 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.
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.
I'm not a Docker user. https://news.ycombinator.com/item?id=10269200
> Until this is done, "simply secure" is only until the first compromise.
That's literally true of anything. If you get compromised, burn the machine and recover from a backup.