How would that be stored as a file descriptor?
Bubblewrap is failing with:
passwd="$(getent passwd root “${app_user}” nobody)"
group="$(getent group root “${app_user}” nobody)"
...
10< <${passwd}
11< <${group}
1 Like
1 Like
Similar syntax as this:
12< ${seccomp_filter} \
10< <(getent passwd root ${app_user} nobody) \
becomes
10< "$varname" \
or
10< "${varname}" \
That doesn’t work. It fails with an error:
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin 11< root:x:0: 12< /var/cache/sandbox-app-launcher-autogenerated/seccomp-filter.bpf /var/cache/sandbox-app-launcher-autogenerated/symlinks/bash : line 1: root:x:0:0:root:/root:/bin/bash: Permission denied
1 Like
Could be because of the double quotes / spaces / newline issue. The bash
-c part needs to be fixed first.
1 Like
…
That might be good since less complexity is always nice but not necessary since I just figured it out Start a D-Bus session bus inside the sandbox by madaidan · Pull Request #28 · Kicksecure/sandbox-app-launcher · GitHub
The dbus-launch program from the dbus-x11 package can easily setup a D-Bus session bus for the user.
This way, processes in the same sandbox can communicate to each other via D-Bus but they can’t communicate with processes outside of the sandbox.
1 Like
Actually, don’t merge that yet. It runs the actual program outside of the sandbox and only the D-Bus daemon inside.
1 Like
What if we change "${symlink_dir}/${app_name}" to a wrapper script that executes dbus-launch and then "${app_path}" instead of a symlink?
1 Like
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