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...
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.
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.
https://github.com/evilsocket/opensnitch https://github.com/kushaldas/unoon https://github.com/nsntrace/nsntrace https://wiki.debian.org/PrivacyIssues#Detection_tools
This is reasonable. Can someone recommend a tool (preferably in the Ubuntu repos) for doing that?
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