Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: option to bind to 127.0.0.1 instead of 0.0.0.0 in launchd.plist for mac #306

Open
e28eta opened this issue Feb 11, 2022 · 3 comments

Comments

@e28eta
Copy link

e28eta commented Feb 11, 2022

I’m fine if you decide this is WONTFIX, but I think it’s worth the trouble. This is specific to the launchd.plist created on macOS.

I believe that, security-wise, it’s better to have fewer services on a development machine listening to public requests. puma-dev -install binds to 0.0.0.0, and that opens up all of the services to any machine that can reach it over the network. I think the /status api makes it easy to enumerate the dev services, and then a malicious actor (or the company’s red team) can explore at will (and iirc I’ve seen a vuln in Sketch get turned into arbitrary file access as an internal example for why this can be bad).

I won’t go so far to ask that 127.0.0.1 become the default (although secure by default is arguably better), but IMO it’d be a really great option to provide.

I realize the nip.io feature relies on 0.0.0.0, and some people will definitely want to keep 0.0.0.0. However, providing documentation & an easy way to make this safer & more secure seems like a net win to me. If you’re willing to make a “breaking” change, requiring explicit action before allowing external access does seem reasonable to me.

I certainly know enough to edit the plist and unload/load it, but I think it’s the kind of thing most people won’t consider unless it’s mentioned in the readme and/or offered as a programmatic option. Especially if they’re regenerating the plist occasionally (for example #112).

Thanks for your work on this tool!

@cjlarose
Copy link
Member

I like the idea of adding this as an option. I understand a lot of people depend on the 0.0.0.0 for being to access puma from VMs or stuff like that, but I don't love that if I'm on a public Wi-Fi network, anyone can connect to my puma apps.

@nonrational
Copy link
Member

Adding something like -install-bind-localhost or similar sounds like a fine idea.

Re: making this the default behavior (and making the flag -install-bind-public or something), there's a slowly growing list of default behavior that I'd like to be able to make non-default. Prob good to start tracking a wishlist for 1.0.

@tcannonfodder
Copy link

What if there was a -listen-hosts flag, similar to -d, that allowed the user to specify what the HTTP server should listen on? I wrote about this some here; the gist is that running puma-dev in the foreground only listens on 127.0.0.1, without the ability to change where the socket is listening. Being able to specify what addresses are acceptable would be a huge boon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants