I did that. The pull request can be merged now. Ristretto works perfectly.
1 Like
This branch has conflicts that must be resolved
Depends: sudo, bubblewrap, apparmor, libseccomp-dev, helper-scripts,
${misc:Depends}
dbus-x11, ${misc:Depends}
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?
cat <<EOF > "${wrapper_dir}/${app_name}"
#!/bin/bash
dbus-launch
${app_path} \${@}
EOF
${app_path} \${@}
should be
"${app_path}" "\${@}"
The actual wrapper script should include "${@}".
${@} needs to be quoted (in most cases).
app_path needs to be quoted too so it does not expand.
1 Like
In that case sandbox-app-launcher shouldn’t start dbus-launch unconditionally for all applications if these can run without?
1 Like
That probably won’t be needed. It doesn’t have many dependencies.
I fixed the merge conflict but it’s still saying there’s a conflict Start a D-Bus session bus inside the sandbox by madaidan · Pull Request #28 · Kicksecure/sandbox-app-launcher · GitHub
<<<<<<< dbus
--ro-bind ${wrapper_dir}/${app_name} ${wrapper_dir}/${app_name} \
=======
--ro-bind ${symlink_dir}/${app_name} ${symlink_dir}/${app_name} \
>>>>>>> master
This is meant to be changed. It isn’t a conflict.
I wonder if this will break IME’s such as fcitx, since they require dbus.
I will try to test this on my system.
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.
1 Like
yoshidako via Whonix Forum:
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.
Sorry, I probably shouldn’t take Firefox / port as an example, I am thinking about firewall based on host / port.
e.g.
- Thunderbird is granted network permission to (and only to) user.mail.example.com
- User is using thunderbird to read email, and it’s compromised.
- The malware can now read all user’s email, but can’t send them back to it’s server due to the whitelist firewall.
(The malware can still try to send data out using a whitelisted host, but that’s gonna to be much harder.)
1 Like
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:
Previous discussions:
Image copyright Subgraph OS:
1 Like
There’s a per-sandbox dbus daemon now. It probably won’t break due to that.
This would be good but bubblewrap doesn’t support configurable network namespaces yet. It’s either an empty net namespace or none at all.
Maybe we could use ip netns for this though. It’s on the TODO list sandbox-app-launcher/usr/bin/sandbox-app-launcher at master · Kicksecure/sandbox-app-launcher · GitHub
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.
2 Likes
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:
- No IPC namespace
- No unix domain socket restrictions (the apparmor
unixrule) - No fine-grained signal restrictions (the apparmor
signalrule) - Netlink? (AF_NETLINK is allowed in the seccomp filter)
3 Likes
@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
1 Like
Yes, it’s still not finished yet. You can test it out if you’d like and report back.
I don’t think so. It should just use the sandbox-app-launcher profile.
2 Likes
What is the difference between this sandbox and the sandbox in Flatpak or Snaps?
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.
1 Like
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:
1 Like
RebeccaBlackOS is a Debian based distro for prototyping all Wayland supporting DEs and window managers. Let’s see if there’s anything on there that is available in Debian and that can be used in XFCE (or maybe in its place if this is important enough).
2 Likes
1 Like
There is 1 issue with this though and that’s that we need unprivileged user namespaces enabled for it to work. bubblewrap sets the no_new_privs flag which prevents executing setuid binaries (which Firefox/Chromium fallback to when there are no user namespaces). So, we need to set the kernel.unprivileged_userns_clone=1 sysctl for sandbox-app-launcher to work with the Firefox/Chromium sandbox.
Chromium fails with an error when starting it without user namespaces:
The setuid sandbox is not running as root. Common causes:
* An unprivileged process using ptrace on it, like a debugger.
* A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[9:9:0528/021452.679452:FATAL:zygote_host_impl_linux.cc(186)] Check failed: ReceiveFixedMessage(fds[0], kZygoteBootMessage, sizeof(kZygoteBootMessage), &boot_pid).
Firefox however goes on fine while the sandbox silently fails and it pretends that it’s active.
I don’t know how to workaround this other than setting the sysctl above (which exposes tons of kernel attack surface so it’s not a good solution at all).
2 Likes