4 ms·

Does this mean that MacOS packet filtering does work as expected, and can block any/all traffic, including traffic to Apple? That's good, and what I would hope,

Does this mean that MacOS packet filtering does work as expected, and can block any/all traffic, including traffic to Apple? That's good, and what I would hope, but then I'm a little confused about what nastiness Apple is doing in Big Sur related to firewalls. Time to dig in, I guess.

pram 6y ago
That problem is different: whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)
- gruez 6y ago
  >whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts) This sentence suggests that there's no way to filter/vpn whitelisted traffic, but this is clearly not the case, as evidenced by this article. Furthermore, it's still possible to block/filter traffic on a whole machine basis by using the Packet Tunnel Provider API. https://news.ycombinator.com/item?id=25113039 https://news.ycombinator.com/item?id=25113039
  - pram 6y ago
    You have poor reading comprehension if you think thats what I said.
floatingatoll 6y ago
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.
- pwinnski 6y ago
  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.
  - floatingatoll 6y ago
    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.)
- ballenf 6y ago
  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.
  - floatingatoll 6y ago
    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?".
whazor 6y ago
A VPN provides internet connectivity, therefore it is more like a partially broken internet connection instead of a firewall.
- penagwin 6y ago
  This is the best description of a "programmer solution" ever.
- fgonzag 6y ago
  Doesn't a VPN work over the internet (in order to access a local network). So I wouldn't say it provides internet connectivity (as you already need to be connected to the internet to connect to a VPN). A VPN simply gives you access to a local network. A specific use of a VPN is masking your internet traffic as if it came from that local network, but there are many uses besides it.
zepto 6y ago
The nastiness is based on misunderstanding of what Apple is doing, and of how their API’s work, coupled with a healthy distrust for large organizations. The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.

pram 6y ago

That problem is different: whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)

gruez 6y ago
>whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts) This sentence suggests that there's no way to filter/vpn whitelisted traffic, but this is clearly not the case, as evidenced by this article. Furthermore, it's still possible to block/filter traffic on a whole machine basis by using the Packet Tunnel Provider API. https://news.ycombinator.com/item?id=25113039 https://news.ycombinator.com/item?id=25113039
- pram 6y ago
  You have poor reading comprehension if you think thats what I said.

floatingatoll 6y ago

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.

pwinnski 6y ago
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.
- floatingatoll 6y ago
  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.)
ballenf 6y ago
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.
- floatingatoll 6y ago
  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?".

whazor 6y ago

A VPN provides internet connectivity, therefore it is more like a partially broken internet connection instead of a firewall.

penagwin 6y ago
This is the best description of a "programmer solution" ever.
fgonzag 6y ago
Doesn't a VPN work over the internet (in order to access a local network). So I wouldn't say it provides internet connectivity (as you already need to be connected to the internet to connect to a VPN). A VPN simply gives you access to a local network. A specific use of a VPN is masking your internet traffic as if it came from that local network, but there are many uses besides it.

zepto 6y ago

The nastiness is based on misunderstanding of what Apple is doing, and of how their API’s work, coupled with a healthy distrust for large organizations. The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.