Which is why I never run untrusted code on my servers. Wordpress is not a trusted environment, so don’t run it in the same network as Caddy.
I typically run my PHP code in a Docker container, and Caddy in another container as a proxy over fastcgi to my PHP container.
To clarify what I think @matt meant in that tweet, he was saying “You can write a guide for this”.
Yes, it got me confused 
I wish it was “Caddy is not designed to be ran in environments like that”. At least it’s clear now.
And I forgot to comment this after seeing last reply on twitter - if caddy is designed to host multiple sites on the same network - all of them have access to localhost interface. I haven’t seen any isolation documented (for example linux namespaces support in Caddy), to really isolate loopback/network at all.
I wasn’t looking for any drop-in replacement of Apache or easy way to integrate it. I wasn’t looking for implementing it “my own way”. In this specific case - I just wanted to say that using UDS by default might be better than listening on TCP/IP. That’s it.
As mentioned on twitter - I don’t really want to conflict at all, and I really wish you success with your product. You’ve done much already and I’m really happy to see Caddy available as alternative to the other webservers. Good luck!
Caddy doesn’t, by itself, run arbitrary code.
You’d need to pipe requests over FastCGI to do that with PHP, or proxy to some other web application.
Just like @francislavoie, I run my PHP in a Docker container, which neatly kills the “curl localhost with a PHP script” idea dead. Don’t allow arbitrary code to run on your Caddy host and the standard admin endpoint does not become vulnerable to this particular attack. Alternatively, if you want to allow running arbitrary code on your Caddy host, secure your admin endpoint.
Just because Caddy isn’t designed for out-of-the-box deployment in a shared web hosting environment doesn’t mean it should never be used ever for this purpose.
You can’t just install Apache or nginx either and BAM! shared web host automatically. Configuration is involved. In Caddy’s case, some security concerns should be addressed as part of the deployment, depending on how your shared hosting is configured.
I can install Apache, Nginx or LiteSpeed/OpenLiteSpeed and none of them would let any other unprivileged user to read and write the configuration of the webserver by default.
Quick summary of what was it all about:
Initial suggestion:
I’d recommend Caddy to use UDS instead of TCP/IP for managing admin interface by default. Not for me. For others, who are not aware they’re exposing the read/write access to anyone having access to loopback interface. People might not know all the other unprivileged users on their computers can change their configuration by default.
I know you might say “Linux/FreeBSD/MacOS” manages unprivileged users in a *wrong way, “if you run Caddy, you should not have any unprivileged users on your system” or “you should modify the way how those systems create unprivileged accounts, and forbid access to loopback interface”. That’s even without any ‘hosting’ in mind. Simply, any new unprivileged user even on desktop environment. But it’s not about it. It was all just a suggestion to change the default until Caddy v2 is not stable and end-customers aren’t used to exposed admin interface by default.
Reactions to the suggestion to change the default:
I’m really not going to argue about UDP socket being more secure that TCP/IP. Or how FreeBSD/MacOS/Linux handles unprivileged users by default.
If someone has any interest to see Caddy supported on control panels - I might still be able to dedicate my free time for implementation in the future, totally as a donation for the community/spread of the webserver.
At this time I really wouldn’t like to cause that anger and confrontation, which, for some reason is here. I really had only good intentions
Neither does Caddy.
When you install PHP, and allow users to upload arbitrary PHP files, and then execute them, you are configuring the web server to allow unprivileged users to write Caddy server configuration if they know how to exploit this hole.
But! Luckily, it only takes a tiny amount of configuration for you to protect Caddy from this. You can run this setup if you want to, and Caddy will happily oblige! Just move the admin endpoint to a socket or even turn it off.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.