Provide a local, secure configuration example for inclusion in Homebrew

[ghost]

I've been running blocky for a while and it's been an excellent, fast DNS proxy and adblocker. blocky has replaced pihole on my home network but where it's been super useful is running as a local service on my MacBook for adblocking and trackblocking purposes while traveling, at the office, at a coworker space, or at a cafe. Not only that, caching makes webbrowsing a ton faster especially while on slow, unstable networks.

Though blocky isn't 1.0 yet, I know many people that would find it helpful to have the service installable from Homebrew so I've submitted a PR. By default, without a config file, blocky listens on all hosts instead of only localhost. That would leave users vulnerable to external requests to sensitive or prohibited domains in their country. I personally have to worry about that. So I provided a basic configuration in that PR with enough to get someone going however Homebrew maintainers requested that a secure config be provided by upstream. Would you consider including a basic configuration in the docs folder specifically for Homebrew?

https://github.com/Homebrew/homebrew-core/pull/120963

[ThinkChaos]

I agree that changing the default from all hosts to localhost only would be nice security wise. The docker image should keep the all hosts by default though since it container runtimes have a firewall by default it's not a security issue and helps with usability.

@0xERR0R any thoughts on changing this?
IMO it's a good moment to consider this since the development branch already has backwards incompatible config changes from #771.

[0xERR0R]

I think the default behavior should be: blocky listens on all interfaces, since this is a common use case. We can provide some example configuration files for different usage scenarios, but it is not so easy:

• Which upstream servers should we use? "8.8.8.8" and "1.1.1.1" are fast but some people say, "oh no google is evil, we need more privacy". Some people say "we can't take plain DNS because it is insecure and/or my provider blocky traffic on port 53". We can take DoH servers from some free projects, but they are slower and the speed is depending on users location.
• Which blocklists/whitelists should we use? Without any blocklist - I think most uses want to block some ads. With some small ad-blocking list - ok, could be good enough, but what is about tracker? Some users use facebook, some users hate facebook. Facebook aps have problems if some facebook domains are blocked...

Also relevant Issue: https://github.com/0xERR0R/blocky/issues/380

[ThinkChaos]

Since you mention it, as part of #380, we'd need to change the default port to be >1024. Which is also an uncommon config, but a better default.
I think of listening on localhost similarly: it's a less common config, but as a default it's more common (all distribs/package managers I know do this) and more secure. Secure by default is pretty important IMO and users should opt-in to opening the server to other machines by specifying IPs in the config.

I agree choosing defaults for upstreams and blocklists is not possible.
What if we set the defaults be conservative (listen on localhost:5353, upstream=system resolver, no blocklists, etc.), and rely on the example config to provide something that covers the more common use cases?
Most users will probably copy the whole example config to get started, so it wouldn't add any overhead for them. And the defaults would work out of the box, be secure and non opinionated.

[ghost]

Which upstream servers should we use?

I can see that you want to remain neutral so what about deferring to the list of DoH providers included in Firefox?

https://wiki.mozilla.org/Security/DOH-resolver-policy#Conforming_Resolvers

[ghost]

Which blocklists/whitelists should we use?

These are tough decisions so I recommend keeping the scope of the Homebrew configuration to providing just enough config to get blocky running as a replacement DNS resolver on a MacOS device without exposing the service to the outside world. Then to help users make full use of the capabilities of blocky, link to the example config at docs/config.yml at the top of the config file as a comment and provide commented-out blocklist/allowlist sections with hints like "If you would like to set up adblocking, find adblocking lists on the internet and add them here."

[0xERR0R]

Since you mention it, as part of #380, we'd need to change the default port to be >1024. Which is also an uncommon config, but a better default. I think of listening on localhost similarly: it's a less common config, but as a default it's more common (all distribs/package managers I know do this) and more secure. Secure by default is pretty important IMO and users should opt-in to opening the server to other machines by specifying IPs in the config.

Why do you want to change the default port to >1024? Docker image runs already with non-root user and port 53. For binary installation user can use setcap. From security point of view, I agree, config should be more restrictive. But I think the default config should just run in the most cases. The common use case is to run blocky on a network device on local network and in this case it should listen for incoming connections. So IMHO, I would be better to leave the default config (listen to all interfaces) and user should restrict it for special use cases (for example using blocky on a local machine).

We can provide different config files and link them with a use case description on the documentation page, what do you think?

[ghost]

Anyone with a home network of special purpose devices will be expecting blocky to listen on all hosts but likely be configuring their instance of blocky for adblocking, logging, metrics, etc. anyways. Anyone running blocky in the cloud will also be configuring it too, even if they're locking it down to be available only through wireguard. So defaults for experienced users aren't so important. Plus blocky has descriptive docs and a well-commented example config.

However a regular MacBook user, maybe a beginning developer, installing blocky as a local adblocker through Homebrew shouldn't be left exposed to the world. A malicious actor making inappropriate or sensitive requests to your laptop isn't that much of a security issue but leaving an inexperienced user vulnerable to that doesn't seem right. Can we provide a sane config file specifically for Homebrew? It's not like we're trying to bring blocky to the masses. But think about what a Homebrew user installing blocky (or any service/software) expects and maybe don't vengefully punish people starting out trying to see what this privacy thing is all about for not reading the manual or knowing how to properly configure a privileged port service. Blocky is excellent software; more people should be trying it!

[ThinkChaos]

We can provide different config files and link them with a use case description on the documentation page, what do you think?

Your call.
But for the record, I think this will cause more work both here (maintain more configs) and downstream (override defaults), and see it as just a matter of time before there's a vulnerability in blocky (counting dependencies) that is exposed by default.

For binary installation user can use setcap.

That's an extra step that requires root, so IMO is not valid for "blocky should run without config".

[ghost]

A new pull request has been opened to include blocky in homebrew-core because the last one was closed.

https://github.com/Homebrew/homebrew-core/pull/127041

[ghost]

blocky is now available in Homebrew. The example config was sufficient.

[ghost]

https://formulae.brew.sh/formula/blocky