Remix.run Logo
▲ hparadiz 3 hours ago

I can't believe I have to write this out in this thread of all places but there is a way to do this.

You make sure www-data CANNOT write ANYWHERE on disk. Not /tmp/ Not to /var/www/. No where.

Then make sure your sudoers has nothing weird in it.

Finally disable www-data's ability to run basically anything that isn't required for the operation of your httpd or php-fpm et al.

You then harden it further and further until an RCE does not matter because it's incapable of doing anything.

tldr always treat httpd as untrusted.

▲matja 2 hours ago | parent | next [-]

Good advice if you're not using the default PHP session settings, but using default settings this means sessions can't be created. At best, that means no-one can log-in. At worst, it completely breaks the site (for those that depend on sessions even for unauthenticated users).

Also: https://stopdisablingselinux.com/ - SELinux can mitigate this.

▲echoangle an hour ago | parent | prev | next [-]

How do you handle file uploads then? Isn’t that handled by the same process writing the uploaded files to disk?

▲trog 3 hours ago | parent | prev | next [-]

But then WordPress stops working :)

▲hparadiz 3 hours ago | parent [-]

They were talking about critical systems :)

▲trog 3 hours ago | parent [-]

Heh, but for better or for worse, a bunch of people have built businesses out of WordPress and its ecosystem. One of them is my aunt, which is why (as a designated family tech support person, though she does have a part time developer) I'm watching this thread closely!

▲bpye 3 hours ago | parent | prev [-]

R/w access to your production database is still a problem, though yes less bad than world read/write.

And also relies on the target being patched against any Linux EoP...