7 ms·

> With the latest releases of Android and iOS, we’re back to where we started. Both now prompt you the first time an app asks for access. Both give you regular

> With the latest releases of Android and iOS, we’re back to where we started. Both now prompt you the first time an app asks for access. Both give you regular reminders of which apps may be snaffling your data. Both let you manage access and selectively deny apps. Every OS should do this, desktop OSes included. For the last 2 decades I've been using personal firewalls on Windows to do just this, now I use LittleSnitch on Mac (I just hope it's going to keep working on ARM macs), AFWall+ and XPrivacy on Android and miss this level of control terribly on Linux (it sort of can be achieved with AppArmor or SELinux but both are nightmares to use). If only iptables would allow to filter by the executable path and other process parameters - that would be just so awesome. There was such a feature in some 2.x kernel but, sadly, it was deprecated long ago.

messe 6y ago
> now I use LittleSnitch on Mac (I just hope it's going to keep working on ARM macs) It should. Kexts are still allowed, for now. They're almost certainly only a couple of releases away from being deprecated though.
- Fnoord 6y ago
  From the article this HN discussion [1] links to: "We expect the deprecation to become effective with the next major release of macOS. There’s no official release date from Apple, but based on the release schedule of recent years it will not be before this fall. Little Snitch 4 will then not be loaded by the operating system, but there will still be an option to allow the loading." Little Snitch 5 (with NKE) requires a new license. [1] https://news.ycombinator.com/item?id=22677849 https://news.ycombinator.com/item?id=22677849
  - jmull 6y ago
    > Little Snitch 5 (with NKE) requires a new license. There is reasonable pricing for upgrades... LS4 bought within a certain time get a free upgrade, older licenses get a reduced price.
- dmd 6y ago
  https://support.apple.com/en-us/HT210999 https://support.apple.com/en-us/HT210999
  - messe 6y ago
    A WWDC talk confirmed that notarized Kexts will still be allowed, but you'll have to enable that option via MacOS Recovery.
    - saagarjha 6y ago
      As long as they’re using non-deprecated KPIs. Those that are require another trip to Recovery to disable SIP.
- deleted 6y ago
  [deleted]
Fnoord 6y ago
A personal firewall is nothing more or less than a layer-7 firewall which rules you can (somehow) manage as user you are logged in with, with a nice GUI. There is Open Snitch [1] (plus forks/patches) for Linux, if you're after such. [1] https://www.opensnitch.io https://www.opensnitch.io
- qwerty456127 6y ago
  The page you have linked to won't even open. I have witnessed a number of attempts to replicate LittleSnitch on Linux, none of them went far enough to anything near a usable product quality. You need to implement at least some functionality on the kernel level (what LitleSnitch does with a kernel extension) for this, most of the people who care about desktop apps on Linux (me included) lack kernel developer skills.
  - Fnoord 6y ago
    True, its not production quality. Here is an actively developed fork/repo of OpenSnitch [1] [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch
  - gus_ 6y ago
    did you try tinysnitch [0], opensnitch fork [1] or Douane [2]? [1] works pretty well for me. [0] https://github.com/nathants/tinysnitch https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/ https://github.com/Douane/Douane/
- vetinari 6y ago
  Editing the rules as a user with a GUI is the easy part. The more difficult parts are in details: - how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. - what happens to the connection while the firewall is waiting for the user input in the UI? Linux apps handle long timeouts badly - what happens to other connections while the firewall is waiting for the user input in the UI? Right now, unfortunately, whey would have to wait too. - LittleSnitch does interesting heuristic wrt hostname/ip translation - you can get different (or no) hostname via reverse query than the application asked for. You need to monitor what each application is resolving and what answers it get. If you get same IPs for different hostnames for a single application, all bets are off, only application knows which one it connects to (you can eventually learn with DPI, but for that it might be too late). For applications with their own resolvers using DoH/DoT, tough luck. The first problem could be solved at the level of sandbox runtimes (i.e. flatpak et al), i.e. when you know, that the application is running in the namespace belonging to specific flatpak package, you would present that as that specific application, they cannot lie about that anymore but the price is, that you can handle only sandboxed apps; for scripting and so on you still have to find how to distinguish specific instances. For all the other problems, you would have to figure them out.
roel_v 6y ago
I do that too, out of interest, but I'm under no illusion it will help me against data exfiltration or protect my privacy. There is lots of software of which you just don't know what it is, or that plain doesn't work when blocked. Some even crashes when their connect() call doesn't immediately succeed. If you do a few weeks of real world work on a machine and then go back through all system processes you allowed, you ask yourself what half of them even are.
ajross 6y ago
> If only iptables would allow to filter by the executable path and other process parameters - that would be just so awesome. You can do that sort of thing with eBPF these days, either at the network level or via process tracing. It's non-trivial still, though. Lots of the various firwewall automation tools have features like this too. It's definitely a solved problem, but not one with a really clean obvious solution yet.
nix23 6y ago
Not saying your wrong, but you said something about SELinux and AppArmor..if your interested in that stuff you should checkout OpenBSD's pledge: https://man.openbsd.org/man2/pledge.2 https://man.openbsd.org/man2/pledge.2
hathym 6y ago
> If only iptables would allow to filter by the executable path iptables can filter based on the uid ( -m owner --uid-owner {USERNAME}) then, you have to to create a dummy user and launch your executable as that user (su, runuser, ...)
c0l0 6y ago
I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users. Back in the Android 5 (or so) days, I knew what permissions an app I was going to install on my mother's phone was going to ask to be granted _once_, and be done with it. Nowadays, an app might ask for some kind of new permission "on first use", and users on mobile are developing the same habit as users of desktop browsers during the dark ages of expired HTTPS certificates and broken Java Applet signatures had developed out of necessity: "default-ack/OK all the things". The problem is that these days, even very technical people think that you could realistically expect to lie with dogs, and get up without fleas - i.e., install applications and software you cannot trust, and get away without having something bad (like loss of privacy, or maybe exfiltration of data) happen. All thanks to "modern" security constructs like sandboxing. But that is not going to happen - sandboxes have been shattered and broken in the past, as they will continue to get circumvented in the future. There simply is no replacement for trust (in an application, its developers, its distributor, and its operator (if any)), and there are no technical solutions that could somehow replace it in full. Yes, you can make it incrementally less bad to have a hostile agent/app on your machine or phone, but the trouble you're trying to prevent that way will never go away completely. I guess some people just liked to feel "in control" when clicking away their "Norton Professional Antivirus 95 blocked 17 Viruses from damaging your machine today!" messages back in the day, and some apparently cherish clicking "grant 'Sexy FileManager Free Pro' access to your Photos and Videos" today. Personally, I'm actually rather sick of it, and all the security theatre that "modern" application delivery mechanisms like app stores/mobile platforms or stuff like snaps/appimage/younameit would have you participate in. I'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions. I know I can't audit everything, but I feel like I'm much better off with that kind of trade-off, than with the non-solution to the problem I tried to describe above. Edit: Removed a leftover part of a restructured sentence.
- WrtCdEvrydy 6y ago
  The problem isn't the sandbox, it's inherently the issue with lack of fine grained permissions and being unable to revoke permissions after installation. Wanna see a real permission model, look at the BB10 Android Player model. After installation, you could revoke permissions and the player would basically act as if the data from that permission was just empty. App asks for contacts, here's an empty contacts list. Edit: I just did a small hackathon and ended up having to request full BLUETOOTH Access and LOCATION access to connect to a label printer... how is this long term sustainable.
simias 6y ago
>if only iptables would allow to filter by the executable path and other process parameters The problem going down that route is that implementing this opens a huge can of worms. That stuff is easy to spoof, you have to account for thousands of edge cases. It's not for nothing that the answer to "can I know the full path of the binary that was used to spawn <process>?" is generally "it depends" or "it's complicated". And let's not even bring up what happens for interpreters for instance. Parameters are also often easy to spoof and manipulate, although in this case I suppose the kernel could just keep a protected copy of the original parameters for that purpose. I completely get why you want that though, and it would be a great feature to have indeed, but I also completely understand why kernel devs don't want to touch that with a ten foot pole.
- teknopaul 6y ago
  I think it's a great idea mosts apps will not want to spoof the firewall. So while it may not be secure, it would be very helpful for user controlled privacy.
- jfrunyon 6y ago
  Errr... the general answer to "can I know the full path of the binary that was used to spawn <process>?" is "sure, just `readlink /proc/<process>/exe`".
  - saagarjha 6y ago
    Yeah, until the program deletes itself from disk on launch.
    - richardwhiuk 6y ago
      Or edits that value.
canada_dry 6y ago
> LittleSnitch on Mac... miss this level of control on Linux This is such a killer app it's hard to believe that only recently a linux variation has been developed... https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch (the original by evilsocket seems to have been abandoned).
derefr 6y ago
One thing I've been wishing for in the mobile OSes, is for them to copy web browsers, and offer a UI to change all these security/privacy permissions for an app quickly from the context of the app, rather than by going into Settings and navigating down to the app (which nobody ever bothers to do, and especially nobody ever bothers to do more than once—so you can't put stuff that'd be useful to change temporarily in there.) Of course, the naive implementation—giving the app itself control over the system's settings for it—would be a disaster. (I think early iOS had something like that, but quickly got rid of it—right around the time the App Store stopped being so heavily curated.) I'm suggesting something more like: if you pull up iOS Control Center while an app is open, it'd have either an "app settings" submenu, or merge "app settings" into the view of system settings. Then, within "app settings", you'd have a little privacy-lock, sort of like the one that appears in a browser's address bar—and which would allow you to change very similar things to what clicking said lock allows you to change in a browser: in est, the states of all the system confirmation prompts the app has triggered. Less on-topic, but contextually-accessible app settings would also allow you to do neat things like provide the ability to set accessibility settings on a per-app basis in an intuitive way, or to start something like Guided Access Mode (https://support.apple.com/en-ca/HT202612 https://support.apple.com/en-ca/HT202612) without needing to enable+remember an arcane gesture. I would especially love the idea of being able to change the perceived system font-size/scaling-factor, or the perceived system language/region, on a per-app basis — basically equivalent to Safari's display settings "A" menu. Maybe even a switch to enable that "monochrome to reduce addictiveness" mode, so you can have it on only within social media apps!
- perryizgr8 6y ago
  > offer a UI to change all these security/privacy permissions for an app quickly from the context of the app Isn't this exactly how Android does it? I long press the app icon, click app info. All permissions, data usage, battery usage, storage usage options and metrics are shown for the app.
  - derefr 6y ago
    That still happens outside the app, though. You have to go back to the home screen, find the app icon. I'm talking about a design where there's no "lookup the app" step in any menu (Settings or Home screen); where instead, you go straight to the foreground app's preferences.
spockz 6y ago
Could this be implemented with iptables rules on a per container/jail basis, like with K8s?

messe 6y ago

> now I use LittleSnitch on Mac (I just hope it's going to keep working on ARM macs) It should. Kexts are still allowed, for now. They're almost certainly only a couple of releases away from being deprecated though.

Fnoord 6y ago
From the article this HN discussion [1] links to: "We expect the deprecation to become effective with the next major release of macOS. There’s no official release date from Apple, but based on the release schedule of recent years it will not be before this fall. Little Snitch 4 will then not be loaded by the operating system, but there will still be an option to allow the loading." Little Snitch 5 (with NKE) requires a new license. [1] https://news.ycombinator.com/item?id=22677849 https://news.ycombinator.com/item?id=22677849
- jmull 6y ago
  > Little Snitch 5 (with NKE) requires a new license. There is reasonable pricing for upgrades... LS4 bought within a certain time get a free upgrade, older licenses get a reduced price.
dmd 6y ago
https://support.apple.com/en-us/HT210999 https://support.apple.com/en-us/HT210999
- messe 6y ago
  A WWDC talk confirmed that notarized Kexts will still be allowed, but you'll have to enable that option via MacOS Recovery.
  - saagarjha 6y ago
    As long as they’re using non-deprecated KPIs. Those that are require another trip to Recovery to disable SIP.
deleted 6y ago
[deleted]

Fnoord 6y ago

A personal firewall is nothing more or less than a layer-7 firewall which rules you can (somehow) manage as user you are logged in with, with a nice GUI. There is Open Snitch [1] (plus forks/patches) for Linux, if you're after such. [1] https://www.opensnitch.io https://www.opensnitch.io

qwerty456127 6y ago
The page you have linked to won't even open. I have witnessed a number of attempts to replicate LittleSnitch on Linux, none of them went far enough to anything near a usable product quality. You need to implement at least some functionality on the kernel level (what LitleSnitch does with a kernel extension) for this, most of the people who care about desktop apps on Linux (me included) lack kernel developer skills.
- Fnoord 6y ago
  True, its not production quality. Here is an actively developed fork/repo of OpenSnitch [1] [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch
- gus_ 6y ago
  did you try tinysnitch [0], opensnitch fork [1] or Douane [2]? [1] works pretty well for me. [0] https://github.com/nathants/tinysnitch https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/ https://github.com/Douane/Douane/
vetinari 6y ago
Editing the rules as a user with a GUI is the easy part. The more difficult parts are in details: - how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox. - what happens to the connection while the firewall is waiting for the user input in the UI? Linux apps handle long timeouts badly - what happens to other connections while the firewall is waiting for the user input in the UI? Right now, unfortunately, whey would have to wait too. - LittleSnitch does interesting heuristic wrt hostname/ip translation - you can get different (or no) hostname via reverse query than the application asked for. You need to monitor what each application is resolving and what answers it get. If you get same IPs for different hostnames for a single application, all bets are off, only application knows which one it connects to (you can eventually learn with DPI, but for that it might be too late). For applications with their own resolvers using DoH/DoT, tough luck. The first problem could be solved at the level of sandbox runtimes (i.e. flatpak et al), i.e. when you know, that the application is running in the namespace belonging to specific flatpak package, you would present that as that specific application, they cannot lie about that anymore but the price is, that you can handle only sandboxed apps; for scripting and so on you still have to find how to distinguish specific instances. For all the other problems, you would have to figure them out.

roel_v 6y ago

I do that too, out of interest, but I'm under no illusion it will help me against data exfiltration or protect my privacy. There is lots of software of which you just don't know what it is, or that plain doesn't work when blocked. Some even crashes when their connect() call doesn't immediately succeed. If you do a few weeks of real world work on a machine and then go back through all system processes you allowed, you ask yourself what half of them even are.

ajross 6y ago

> If only iptables would allow to filter by the executable path and other process parameters - that would be just so awesome. You can do that sort of thing with eBPF these days, either at the network level or via process tracing. It's non-trivial still, though. Lots of the various firwewall automation tools have features like this too. It's definitely a solved problem, but not one with a really clean obvious solution yet.

nix23 6y ago

Not saying your wrong, but you said something about SELinux and AppArmor..if your interested in that stuff you should checkout OpenBSD's pledge: https://man.openbsd.org/man2/pledge.2 https://man.openbsd.org/man2/pledge.2

hathym 6y ago

> If only iptables would allow to filter by the executable path iptables can filter based on the uid ( -m owner --uid-owner {USERNAME}) then, you have to to create a dummy user and launch your executable as that user (su, runuser, ...)

c0l0 6y ago

I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users. Back in the Android 5 (or so) days, I knew what permissions an app I was going to install on my mother's phone was going to ask to be granted _once_, and be done with it. Nowadays, an app might ask for some kind of new permission "on first use", and users on mobile are developing the same habit as users of desktop browsers during the dark ages of expired HTTPS certificates and broken Java Applet signatures had developed out of necessity: "default-ack/OK all the things". The problem is that these days, even very technical people think that you could realistically expect to lie with dogs, and get up without fleas - i.e., install applications and software you cannot trust, and get away without having something bad (like loss of privacy, or maybe exfiltration of data) happen. All thanks to "modern" security constructs like sandboxing. But that is not going to happen - sandboxes have been shattered and broken in the past, as they will continue to get circumvented in the future. There simply is no replacement for trust (in an application, its developers, its distributor, and its operator (if any)), and there are no technical solutions that could somehow replace it in full. Yes, you can make it incrementally less bad to have a hostile agent/app on your machine or phone, but the trouble you're trying to prevent that way will never go away completely. I guess some people just liked to feel "in control" when clicking away their "Norton Professional Antivirus 95 blocked 17 Viruses from damaging your machine today!" messages back in the day, and some apparently cherish clicking "grant 'Sexy FileManager Free Pro' access to your Photos and Videos" today. Personally, I'm actually rather sick of it, and all the security theatre that "modern" application delivery mechanisms like app stores/mobile platforms or stuff like snaps/appimage/younameit would have you participate in. I'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions. I know I can't audit everything, but I feel like I'm much better off with that kind of trade-off, than with the non-solution to the problem I tried to describe above. Edit: Removed a leftover part of a restructured sentence.

WrtCdEvrydy 6y ago
The problem isn't the sandbox, it's inherently the issue with lack of fine grained permissions and being unable to revoke permissions after installation. Wanna see a real permission model, look at the BB10 Android Player model. After installation, you could revoke permissions and the player would basically act as if the data from that permission was just empty. App asks for contacts, here's an empty contacts list. Edit: I just did a small hackathon and ended up having to request full BLUETOOTH Access and LOCATION access to connect to a label printer... how is this long term sustainable.

simias 6y ago

>if only iptables would allow to filter by the executable path and other process parameters The problem going down that route is that implementing this opens a huge can of worms. That stuff is easy to spoof, you have to account for thousands of edge cases. It's not for nothing that the answer to "can I know the full path of the binary that was used to spawn <process>?" is generally "it depends" or "it's complicated". And let's not even bring up what happens for interpreters for instance. Parameters are also often easy to spoof and manipulate, although in this case I suppose the kernel could just keep a protected copy of the original parameters for that purpose. I completely get why you want that though, and it would be a great feature to have indeed, but I also completely understand why kernel devs don't want to touch that with a ten foot pole.

teknopaul 6y ago
I think it's a great idea mosts apps will not want to spoof the firewall. So while it may not be secure, it would be very helpful for user controlled privacy.
jfrunyon 6y ago
Errr... the general answer to "can I know the full path of the binary that was used to spawn <process>?" is "sure, just `readlink /proc/<process>/exe`".
- saagarjha 6y ago
  Yeah, until the program deletes itself from disk on launch.
  - richardwhiuk 6y ago
    Or edits that value.

canada_dry 6y ago

> LittleSnitch on Mac... miss this level of control on Linux This is such a killer app it's hard to believe that only recently a linux variation has been developed... https://github.com/gustavo-iniguez-goya/opensnitch https://github.com/gustavo-iniguez-goya/opensnitch (the original by evilsocket seems to have been abandoned).

derefr 6y ago

One thing I've been wishing for in the mobile OSes, is for them to copy web browsers, and offer a UI to change all these security/privacy permissions for an app quickly from the context of the app, rather than by going into Settings and navigating down to the app (which nobody ever bothers to do, and especially nobody ever bothers to do more than once—so you can't put stuff that'd be useful to change temporarily in there.) Of course, the naive implementation—giving the app itself control over the system's settings for it—would be a disaster. (I think early iOS had something like that, but quickly got rid of it—right around the time the App Store stopped being so heavily curated.) I'm suggesting something more like: if you pull up iOS Control Center while an app is open, it'd have either an "app settings" submenu, or merge "app settings" into the view of system settings. Then, within "app settings", you'd have a little privacy-lock, sort of like the one that appears in a browser's address bar—and which would allow you to change very similar things to what clicking said lock allows you to change in a browser: in est, the states of all the system confirmation prompts the app has triggered. Less on-topic, but contextually-accessible app settings would also allow you to do neat things like provide the ability to set accessibility settings on a per-app basis in an intuitive way, or to start something like Guided Access Mode (https://support.apple.com/en-ca/HT202612 https://support.apple.com/en-ca/HT202612) without needing to enable+remember an arcane gesture. I would especially love the idea of being able to change the perceived system font-size/scaling-factor, or the perceived system language/region, on a per-app basis — basically equivalent to Safari's display settings "A" menu. Maybe even a switch to enable that "monochrome to reduce addictiveness" mode, so you can have it on only within social media apps!

perryizgr8 6y ago
> offer a UI to change all these security/privacy permissions for an app quickly from the context of the app Isn't this exactly how Android does it? I long press the app icon, click app info. All permissions, data usage, battery usage, storage usage options and metrics are shown for the app.
- derefr 6y ago
  That still happens outside the app, though. You have to go back to the home screen, find the app icon. I'm talking about a design where there's no "lookup the app" step in any menu (Settings or Home screen); where instead, you go straight to the foreground app's preferences.

spockz 6y ago

Could this be implemented with iptables rules on a per container/jail basis, like with K8s?