141–150 of 158 posts
Earlier quoted context omitted.
This already exists. Apple processes can bypass app-specific filters (NEFilterDataProvider), but not system-wide firewalls (like the built-in BPF), VPN configurations, etc.
I thought they DID bypass vpn connections. Also, apple will routinely clear your pf rules when installing stuff.
Earlier quoted context omitted.
Downvote? I'm confused. This whole "Apple gets to bypass firewalls" thing is IMO a huge deal. Whoever figures out how to make a system-wide firewall that can block everything including "unblockable" Apple network traffic likely deserves (again: IMO) all the attention we can give them.
This already exists. Apple processes can bypass app-specific filters (NEFilterDataProvider), but not system-wide firewalls (like the built-in BPF), VPN configurations, etc.
Earlier quoted context omitted.
Its a firewall, it either works or it doesn't. If you don't allow me to block your services, then your firewall simply doesn't work.
Beyond being technically incorrect (a firewall with a whitelist still works) you're missing the larger point: if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it. Run this command to look at the list of applications which aren't subject to the application-level firewall (the lower-level packet filter does still apply): defaults read /Syst…
Does it really have to spelled out to you - it is meaningless to use an application firewall when you are not the one creating and controlling the whitelist!!
> if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it.
Many of us don't - and that is why an operating system is extendable and we use third-party softwares on it. Just like we use anti-virus software on our OS. And sometimes we also use non-Apple softwares for products or features over Apple's because the third-party has a better product.
> The person I replied to had an even sillier version
Silly for you who are just evading the actual issue and instead want to try and focus the debate to "let's discuss your beliefs instead, and pretend everything is normal with an OS vendor deliberately crippling a useful software".
Yes, Apple does want access to your personal data. Yes, the deliberate crippling of firewalls on the macOS is an an ATTACK by Apple against its users towards this end. And yes, malwares can exploit the whitelist to hijack these whitelisted process.
All the other irrelevant babble you spouted on how you have to be "firewall admin" itself is laughable when all you have to do is toggle a button to control whether an app is allowed to connect to the internet.
> Defending against the OS vendor is close to impossible
It needn't be if the OS vendor has good intentions. And that's no excuse to shut up and not criticize them.
Earlier quoted context omitted.
Threre are no indications that Apple is willing to compromise and allow application firewalls to block Apple softwares that Apple believes should be able to access the internet, even if the user doesn't want it too. It's a gross invasion of privacy, and a security risk. (By the way, even in Lulu, some Apple system software - apsd, automount, helpd, mDNSResponder, mount_nfs, mount_url, ocspd, sntp, trustd - are whitel…
What is point then to have such app all? if you can’t control _all_ connections then it appears useless. What is the proper solution? Something on router? Is there a way? Can Openwrt do the job of protecting privacy properly?
Use a better OS. Seriously, just use Linux if you want that level of control. Most users are happy to give up control in exchange for pretty graphics, easy UI, etc.
Earlier quoted context omitted.
Beyond being technically incorrect (a firewall with a whitelist still works) you're missing the larger point: if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it. Run this command to look at the list of applications which aren't subject to the application-level firewall (the lower-level packet filter does still apply): defaults read /Syst…
> Beyond being technically incorrect (a firewall with a whitelist still works) ... Does it really have to spelled out to you - it is meaningless to use an application firewall when you are not the one creating and controlling the whitelist!! > if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it. Many of us don't - and that is why an opera…
You need to think about this from a security perspective rather than that initial emotional response. You claim but have no evidence that Apple wants personal data and will not obey their own privacy policy. Again, if you believe that, use something else because that level of unethical behavior is incompatible with the level of trust you’re placing in them.
Continuing the theme, Apple did not “deliberately cripple” the firewall. ipfw still works, a VPN still gets all of your traffic, but when they added a new user-level socket filter they made the decision to exempt core services which are either unsafe to disable or only have effect when you voluntarily opt-in to their terms of service. You may disagree with this but it’s not an attack without some evidence of malice.
And, yes, it’s possible that someone can find an exploit in something like Photos or iMessage. The question you should be asking is how often that would stop an attacker because they wouldn’t have permission to disable your local firewall rules. You can click allow, and that’s why malware commonly approves itself, too.
This kind of local firewall is appealing for giving the illusion of security but most people are not going to be able to meaningfully assess the risk (“oh, a connection to AWS. Narrows it right down!”) and in practice these tools train people to click allow because after thousands of false positives that’s always worked. Enabling one for the apps on the list is especially prone to that because they only access Apple’s own servers.
Earlier quoted context omitted.
Without saying anything about OSX in particular , any operating system that requires network access to log in is a user-hostile piece of shit, and the linked bug#284 pretty well implies that that is in fact the case. It's entirely possible that the problem is due to incompatibities with new OS code or bugs in the firewall program (edit: ie, your case a and case b), but evidence in the bug report pretty clearly sugges…
You're making a mistake jumping to the assumption of malice rather than thinking about all of the other possibilities. This class of bugs is pretty common: people sometimes test software without a network connection at all but its far less common to test with one which drops packets but does not return errors. I've had to fix variations of this problem on Windows, Linux, and things like VMware's HA module. My guess w…
That sounds pretty common to me.
Earlier quoted context omitted.
You're making a mistake jumping to the assumption of malice rather than thinking about all of the other possibilities. This class of bugs is pretty common: people sometimes test software without a network connection at all but its far less common to test with one which drops packets but does not return errors. I've had to fix variations of this problem on Windows, Linux, and things like VMware's HA module. My guess w…
>its far less common to test with one which drops packets but does not return errors. That sounds pretty common to me.
Earlier quoted context omitted.
> Beyond being technically incorrect (a firewall with a whitelist still works) ... Does it really have to spelled out to you - it is meaningless to use an application firewall when you are not the one creating and controlling the whitelist!! > if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it. Many of us don't - and that is why an opera…
> Yes, Apple does want access to your personal data. Yes, the deliberate crippling of firewalls on the macOS is an an ATTACK by Apple against its users towards this end. And yes, malwares can exploit the whitelist to hijack these whitelisted process. You need to think about this from a security perspective rather than that initial emotional response. You claim but have no evidence that Apple wants personal data and w…
An application firewall is a SECURITY software. Crippling it is stupid. And that is exactly why people are very pissed at Apple for doing so.
> Apple did not “deliberately cripple” the firewall.
Yes, they did - they crippled all APPLICATION firewalls. An application firewall controls what apps can access the internet. By deliberately creating a new API with a BACKDOOR to allow some Apple apps to connect to the internet, and forcing all firewalls to use only that API, Apple is intentionally crippling them.
> they made the decision to exempt core services which are either unsafe to disable or only have effect when you voluntarily opt-in
There are many who have been using such Application firewalls for years together, on previous versions of macOS, blocking such "core" services that they don't care about ... they are "core" only to Apple, not for users who don't use it.
> The question you should be asking is how often that would stop an attacker because they wouldn’t have permission to disable your local firewall rules.
This is just a diversionary argument from the fact that crippling firewalls and giving default internet access to some apps actually weakens the overall security of a system.
> This kind of local firewall is appealing for giving the illusion of security
There is no illusion - if you don't use iCloud, Maps, App Store etc., they don't need to unnecessarily connect to the internet and waste our bandwidth, or worse access and transfer our personal data. The same applies to any app on your system. Their job is to block internet access to specified apps and modern application firewalls do this in a user-friendly.
It is gross abuse by Apple to cripple this ability in their OS.
Earlier quoted context omitted.
> Yes, Apple does want access to your personal data. Yes, the deliberate crippling of firewalls on the macOS is an an ATTACK by Apple against its users towards this end. And yes, malwares can exploit the whitelist to hijack these whitelisted process. You need to think about this from a security perspective rather than that initial emotional response. You claim but have no evidence that Apple wants personal data and w…
> You need to think about this from a security perspective An application firewall is a SECURITY software. Crippling it is stupid. And that is exactly why people are very pissed at Apple for doing so. > Apple did not “deliberately cripple” the firewall. Yes, they did - they crippled all APPLICATION firewalls. An application firewall controls what apps can access the internet. By deliberately creating a new API with a…
Which is exactly what happens now. You’re spending a lot effort protecting against an imaginary problem rather than the kinds of attacks which actually cause problems. If this terrifies you so much, add some ipfw rules and move on. Better yet, think about your threat model and block it at the firewall so you don’t have to rely on Apple to protect you from what you fear Apple will do.
Earlier quoted context omitted.
Would you mind sharing your experience afterwards? The alternatives to SELinux in terms of network filtering seem to be so rare.
I can give you mine, since I use(d) opensnitch for a while. It works quite well but requires a GUI (obviously), it looks like it primarily supports GTK. If you're hoping to use the machine purely from the CLI (like, when sshing into your work machine) it won't work well. It is significantly less powerful than LittleSnitch, some options don't exist (like, allowing access to a domain), but you get similar functionality…
GUI is not GTK, but Qt.
> If you're hoping to use the machine purely from the CLI (like, when sshing into your work machine) it won't work well.
There's no cli tool published yet. There's a PoC though that works well.
> some options don't exist (like, allowing access to a domain)
Since version 1.0.0b you can filter by domain. And in latest version by domain, ip, network, uid, port, command line, command path, cmd environment variables, protocol, or any combination of them. You can't filter by interface, but if aomeone needs it open a new issue.
> It is significantly less powerful than LittleSnitch
What options do you miss?