fix: block Chromium's calls to Google in the companion browser instance

[ggrossetie]

• The shared headless Chromium instance (Mermaid, BPMN, Excalidraw, diagrams.net) reaches out to Google (update.googleapis.com, clients2.google.com, android.clients.google.com, accounts.google.com, www.google.com) as soon as it launches, via several independent built-in subsystems (GCM device checkin, network-time sync, the component updater, ...)
• Disabling each subsystem individually (--disable-component-update, --disable-domain-reliability, --no-pings) still left some of them contacting Google — confirmed by packet capture (tcpdump/tshark)
• Fixed by blocking DNS resolution for *.google.com and *.googleapis.com at the browser level via --host-resolver-rules, so nothing Chromium does can reach Google regardless of which internal subsystem tries

Fixes #2128

[xlsigned]

Wow, that was some rapid response.
Thank you!

[ggrossetie]

Wow, that was some rapid response.
Thank you!

Eh eh! could you please give it a try? I'm a bit torn on the host resolver rules option, particularly for Google Fonts https://fonts.googleapis.com/, but I haven't found a better way to block the calls... 😞

[xlsigned]

Eh eh! could you please give it a try? I'm a bit torn on the host resolver rules option, particularly for Google Fonts https://fonts.googleapis.com/, but I haven't found a better way to block the calls... 😞

I can try later tonight. Need to build/update the docker containers myself, right?
Though I'm not sure or rather I doubt, that I have any diagram sources which rely on fonts being downloadable from fonts.googleapis.com. Otherwise I would have noticed this already (see below).

I'm currently using the workaround with a separate (internal: true) docker network for the companion containers. In fact, none of the containers has ever been able to actually reach google (or rather anywhere outside) from my host, since I'm running docker with iptables: false. The issue actually popped up at our firewall which complained about spoofed IP addresses, since my containers were using their bridge IP as the source address to phone home.

Meanwhile I've learned a lot more about docker networking and I'm running my own set of iptables rules which blocks all traffic from the docker bridges (unless I explicitly allow certain IPs and manually add a MASQUERADE and a FORWARD rule). I still do not like docker to mess with the iptables/nftables on my host.

[xlsigned]

I'm a bit torn on the host resolver rules option, particularly for Google Fonts https://fonts.googleapis.com/ ...

You could always map update.googleapis.com to localhost and *.googleapis.com only when KROKI_SAFE_MODE == secure (the default) or KROKI_SAFE_MODE != unsafe, right?

Also, if people really want to operate kroki in unsafe mode, i.e. allow containers to fetch external resources, they probably (should) have their own iptables/nftables rules in place. Either on top of the docker rules using the DOCKER_USER chain or with iptables[6]: false using the default chains.

Basically:

• Improve the default safe/secure mode, by adding the --host-resolver-rules to map the google domains to localhost.
• Strongly suggest in the documentation to add iptables/nftables rules to only allow access to specific sites, if running in unsafe mode, i.e. deny all by default (which includes google) and whitelist exactly what you need.

[xlsigned]

Eh eh! could you please give it a try?

I can try later tonight. Need to build/update the docker containers myself, right?

@ggrossetie

I've copied the patched index.js from the PR to /usr/local/lib/browser-instance/ of the bpmn, mermaid and excalidraw containers and committed the change to new/fixed images for the companion containers.

When I run a standard docker-compose, i.e. without the internal: true network but with the new/fixed companion images, I can see that the DNS-queries to google are indeed gone (👍🏻) and -- as a consequence -- the HTTP(s) requests, too (👍🏻).

As I already mentioned, I cannot say anything about potential problems with access to fonts.googleapis.com being blocked. My "test set" only contains a simple plantuml mindmap, a simple bpmn diagram, a simple mermaid gitgraph and a very simple excalidraw text box. Those worked fine.