Comment by floatingatoll | Hacker News Reader

Comment by floatingatoll | Hacker News Reader

Parent Full thread

macOS packet filtering in Big Sur is unchanged, offering src/dst host/port/proto filters, as is typically thought of to be a 'firewall'.

macOS content filtering in Big Sur is no longer able to intercept apps on the exclusion list shipped by Apple, and is akin to 'iptables --uid 501' or 'iptables --command firefox-bin' (actual syntax may vary).

The content filtering API can see which user/app originated the traffic, as it's running higher up in the stack; the packet filtering API cannot, as it's running lower down in the stack.

Apps such as Little Snitch allow you to filter network traffic per-application, which can't be done with PF; you need CF for that, and CF no longer extends to Apple core system processes in Big Sur.

Mullvad's blocks are done imprecisely with PF (presumably they deny 17.0.0.0/8), which is why their blocks break various functionality such as the Mac App Store or:

> For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online.

And while they note that it's possible to punch exceptions into the firewall, those exceptions can't be granted per-use, only per-IP.

I wonder if a Little Snitch type application could look at both data flows and correlate the two. Anything that packet filtering detects that isn't also detected by content filtering could itself be handled with custom rules.

It might be able to report that unfiltered traffic occurred, assuming it can detect unfiltered traffic using pcap, but it wouldn't be readily possible to prevent the initial packet from being sent prior to a rule specifically being created to prohibit it.

Operating a system in PF deny-all default would cure this, as long as LS carefully curated a list of PF allows.

It's possible there are external constraints preventing more widespread use of PF, like "Is this allowed on Mac App Store?".

Okay, this makes sense, thanks.

I happen to not use app-level filtering these days, only pi-hole and and packet-firewall stuff, so I guess I'll be unaffected if I ever upgrade.

Bypassing app-level filtering, though, that sucks.

I assume that Apple's reasoning is "Userspace malware shouldn't be able to trivially intercept anti-malware checksum updates".

Trivially is defined as 'click an OK button in a dialog' as the CF permissions process works in Big Sur today.

Malware could still block anti-malware checksum updates with PF, but that requires sudo/root which is 'less easy' than the one-click CF approval process, and PF blocks break so many things on the system that malware can't get away with it without triggering a call to technical support.

(I personally think that much of the issue here is 'macOS background updates can cause $$$$ cellular data drain over wifi-tethered cellular', and that the absence of Low Bandwidth mode in Control Center is one thing that drives users towards these third-party content filters, when they might otherwise not need a third-party product at all.)

Reply on news.ycombinator.com