I was curious how does session notification from system service works -- what if there is no one logged in? What if there are multiple users? How about ssh connections?
The answer is as following:
- user's dbus session is used for notifications. On systemd systems, user's dbus socket is in fixed, predictable location, and only depends on username. The script hardcodes this location.
- The normal install procedure records the username of the user who called "install" command and uses their session for notification [0]. So if user "alice" run the install command, and user "john" is logged in, no notifications will be delivered.
- If installer user is not available, an arbitrary user is chosen [1] (!) and program just expect them to be logged in. This happens when installing a .deb file for example.
- If the user is not logged in, or has logged out, the notifications are enqueued and would be shown once user is logged back in.
Overall, this is a bit simplistic and will fail in some multi-user situations... but it still covers most common cases (a single user on the system) and in the spirit of "lightweight" tool.
Picosnitch tracks every executable that connects to the internet and notifies you the first time something connects, or if the hash changes (it can also check VirusTotal).
There is also a simple curses based UI for browsing and filtering the connection logs (time, executable, hash, domain, IP address, etc).
It was designed using eBPF and fanotify to be extremely reliable, use very little system resources, and does not impact network performance. The entire program is only ~1500 lines.
One thing I forgot to mention is that by using hashes to identify executables, picosnitch can provide more reliable intrusion detection since different executables can appear to be located on the same path.
For example, it can successfully identify whether curl being run from inside a docker container is the same or different from curl being run on your system, even if they both appear to be located at /usr/bin/curl.
To improve performance, hashes are cached based on the device and inode of the executable, and watched with fanotify to trigger a rehash if the executable is modified.
Not sure what your goals are specifically, but even apparmor and selinux can do things like block access to the network, limit read and/or write access to certain directories, limiting what system calls can be made, and notify you of failed attempts.
I didn't (at the time) know that PDFs could "phone home" to report details of the system reading a PDF. A selinux profile denied access to the internet, and it was many months (and 100s if not 1000s of PDFs read) before one attempted network access and denied it. Ubuntu and Redhat (and I'm sure others) have reasonable defaults, so much of the work is already done for you.
>I didn't (at the time) know that PDFs could "phone home" to report details of the system reading a PDF. A selinux profile denied access to the internet, and it was many months (and 100s if not 1000s of PDFs read) before one attempted network access and denied it. Ubuntu and Redhat (and I'm sure others) have reasonable defaults, so much of the work is already done for you.
And does this happen on android aswell? Because a lot of custom rom/ root users run selinux as permissive for compatibility, so these pdfs would have full network access
The answer is as following:
- user's dbus session is used for notifications. On systemd systems, user's dbus socket is in fixed, predictable location, and only depends on username. The script hardcodes this location.
- The normal install procedure records the username of the user who called "install" command and uses their session for notification [0]. So if user "alice" run the install command, and user "john" is logged in, no notifications will be delivered.
- If installer user is not available, an arbitrary user is chosen [1] (!) and program just expect them to be logged in. This happens when installing a .deb file for example.
- If the user is not logged in, or has logged out, the notifications are enqueued and would be shown once user is logged back in.
Overall, this is a bit simplistic and will fail in some multi-user situations... but it still covers most common cases (a single user on the system) and in the spirit of "lightweight" tool.
[0] https://github.com/elesiuta/picosnitch/blob/master/picosnitc...
[1] https://github.com/elesiuta/picosnitch/blob/master/picosnitc...