Unfortunately, this still has the key flaw that has plagued outbound firewalls since their invention:
"Currently, LuLu only supports rules at the 'process level', meaning a process (or application) is either allowed to connect to the network or not. As is the case with other firewalls, this also means that if a legitimate (allowed) process is abused by malicious code to perform network actions, this will be allowed."
In other words, it won't stop malicious Javascript running in your browser from making an outbound connection, which is the most common way for malware to do that.
It does say "currently", but I'm not sure how you would get around this flaw; at any rate, nobody has yet figured out how.
Combining process (source) and destination rule combos, the Little Snitch could be customized to "solve" this issue. Process A is allowed to talk to domains X, Y and Z.
"Solve" not solve because, for me, setting up baseline rule sets was too intrusive to my workflow.
> Combining process (source) and destination rule combos, the Little Snitch could be customized to "solve" this issue. Process A is allowed to talk to domains X, Y and Z.
Ok, and what happens when I want to browse to a different site?
>for me, setting up baseline rule sets was too intrusive to my workflow
It seems like that would be true for anyone that wants to use their browser to go to more than a small number of websites.
> In other words, it won't stop malicious Javascript running in your browser from making an outbound connection, which is the most common way for malware to do that.
This might be possible, if you start off with deny-all as the default and then start manually adding exceptions as you browse.
I would like to see internet access treated as an OS permission that need to be expressly granted by the user, same goes for iOS and Android. I wish this was part of the OS and not something I need to go and install 3rd party apps for. I like the idea of deny all by default.
> I would like to see internet access treated as an OS permission.
That would be nice, but it wouldn't fix the problem I've been talking about, because you would have to give your browser the internet access permission, and the OS has no way of knowing which of the connections your browser is making are legitimate and which are not. Only you know that, which means you would have to continually be interrupting your browsing to approve or disapprove connections.
Let me ask, seriously: if we take the Great Firewall of China, it does all sorts of packet inspection. Why can't this be applied to personal firewalls and inspect the traffic leaving (or coming in) for malicious content being masked as allowed traffic, etc?
There was a company called Packeteer that did traffic shaping/inspection....could any concepts be applied to firewalling as they were to traffic prioritization?
and how does one verify the new exception request is trustworthy. it's enough to drive one mad the whole cat/mouse game of trust/deny. the only winning move is not to play.
And of course, anything local to the machine can only be trusted as long as you are willing to accept that the kernel is not compromised, because it's pretty trivial for a rootkit that is running in the kernel’s context to conceal files, sockets, or even create unreported network interfaces. I remember that Greg Hoglund's rootkit.com contained several first crude (and not so crude) implementations that could do this kind of things (FU springs to mind?) way back in the mid 2000s or thereabouts.
The answer to that, of course, is that if you are really serious about firewalling, said firewall must be a separate device.
also, there's nothing preventing a program from debugging a trusted process, and getting that process to perform the requests for the malicious program.
"Currently, LuLu only supports rules at the 'process level', meaning a process (or application) is either allowed to connect to the network or not. As is the case with other firewalls, this also means that if a legitimate (allowed) process is abused by malicious code to perform network actions, this will be allowed."
In other words, it won't stop malicious Javascript running in your browser from making an outbound connection, which is the most common way for malware to do that.
It does say "currently", but I'm not sure how you would get around this flaw; at any rate, nobody has yet figured out how.