Can could merge that but then I probably split the package into sandbox-app-launcher and sandbox-app-launcher-gui? Reason debus-x11 might pull a lot dependencies which are unwanted for CLI systems.
Or shall sandbox-app-launcher be a GUI only package not installed on CLI systems? Then it could stay as is.
If sandbox-app-launcher should be useful for CLI too, then launching dbus-launch should stay optional - perhaps only if installed?
Maybe we can further split the network permission?
e.g. A browser like Firefox shouldn’t need anything other than 443/80/53, so only allow them when user grant network permission.
In what threat model that would help?
Firefox: maybe
Tor Browser in Whonix: only talks to unix domain socket files
(redirected to Tor). Therefore filtering 443/80/etc. isn’t possible as
that information available at that level.
You’re basically suggesting to expand the sandbox into an application level firewall.
Issue is domain name vs IP but perhaps its solvable.
One can tunnel / leak information through DNS too. But perhaps that could be hindered too.
What also would be useful is reverse DNS. If an application is connecting to an IP it would be more useful to know for users which domain name that represents.
…and a lot more details to be considered…
We don’t have any GUI developers but it’s an interesting idea.
I should re-consider / update my previous opinion on application level firewalls.
And make sure our sandbox isn’t defeated similar to this subgraph issue:
Not much of a priority though as it’s not that important.
This project isn’t meant to create a unique policy for apps. That’s not doable. It’s a generic sandbox. So, things like this example probably aren’t able to be done unless it becomes a permission the user configures but, the average user probably won’t be able to utilize this as it could be too complicated.
Something like the Subgraph firewall does seem interesting though.
Also, the reason network restrictions don’t work on Android is because apps can cause other apps to make network requests (e.g. they can send an intent to the browser to access example.com even though they themselves don’t have network access).
We should cut off dangerous IPC like this in general, not just for network restrictions. The dbus etc. issues are solved but apps can still communicate with SysV IPC since we aren’t using an IPC namespace (due to X). I’m not sure how exploitable this is though.
The current possible IPC issues I know of right now are:
@madaidan Thanks for all the work on this and your other projects. On your Github for this is says “Currently a WIP and not for actual use”. Is that still the case? If this applies bubblewrap plus apparmor to an app do I need to remove the apparmor profile I already use? Thanks
Flatpak and Snap don’t provide meaningful sandboxes. They fully trust the apps and allow them to specify their own policy. The security is optional and apps can just choose not to be sufficiently sandboxed.
Flatpak is especially bad since its permissions are far too vague. One example is the fact that many apps come with the filesystem=home permission which is read-write access to the user’s entire home directory, giving access to all of your personal files and allowing trivial escapes via writing to ~/.bashrc or similar. Another example would be the lack of any restrictions over /sys or /proc (kernel interfaces known for info leaks). etc.
Snap at least has the potential for the policy to be more restrictive but I highly doubt it’s used properly and again, the app decides it.
With sandbox-app-launcher, there is 1 restrictive policy for all apps and the user can control a few important permissions per app.
Pipewire is supposed to be a security conscious successor for Pulseaudio that places restrictions on access. While it was written for Flatpak I don’t see any reason why we couldn’t take advantage of it: