4 ms·
What is the problem here, that is any different from allowing untrusted code on your machine? Yes, if you don't trust your other users you need to lock down you
by mholt 3y ago
What is the problem here, that is any different from allowing untrusted code on your machine? Yes, if you don't trust your other users you need to lock down your system. That's not new or unique to Caddy, and indeed you can lock down Caddy too. Once the machine is popped locally it's already game over, authentication can't prevent that.
- account42 3y agoDefense works in layers. Punching through one of those layers makes securty worse even if that layer was not the first or the primary defense. The problem here is that a priviledged process (and yes, a process that has access to Port 80 and 443 is priviledged even if it doesn't run as root) gives unauthenticated control to less priviledged processes. With good security design you don't lock things down as needed but instead start fully locked down and open up only the accesss you really need.
- rekoil 3y ago> With good security design you don't lock things down as needed but instead start fully locked down and open up only the accesss you really need. This. @mholt what we're arguing for is just to have secure defaults.
- rekoil 3y agoLarge enterprise codebases will almost always have some security vulnerabilities in them but are still considered trusted code. Caddy is a fine alternative for ingress to such applications if you ask me, maybe a little on the immature side, but it's certainly getting there. An admin might absolutely pick Caddy for ingress in order to keep config simple, writing a Caddyfile, and ending up with the aforementioned admin endpoint enabled by mistake.