I read that programs like lxc and docker depend on kernel.unprivileged_userns_clone and apparently browser sandboxes too despite the enrmous security risks this opens. One can intercept and emulate system calls with ptrace, but this opens up another can of worms.
This seems like a showstopper.
They do if you’re running them as an unprivileged user but you can just create the container as root then drop privileges.
Browser sandboxes fallback to a setuid binary if user namespaces aren’t available but sandbox-app-launcher breaks that fallback.
I don’t think that’s a viable approach.
Killing sandbox-app-launcher from the terminal with Ctrl + C doesn’t kill the apps started in it. Should we add something like this to fix it?
exit_handler() {
## Don't leave any left-over processes.
killall -9 -u "${app_user}"
exit
}
trap "exit_handler" INT
We can replace sandbox-app-launcher/sandbox-app-launcher at 8ee5d5b43eaa785fb48547d07eade48196aaaeab · Kicksecure/sandbox-app-launcher · GitHub with exit_handler.
It’s an option but perhaps there’s a better solution. kill -9 doesn’t let the application shutdown gracefully. Data loss might happen. Would be better to ask to shutdown gracefully (sigterm) first and then after timeout forcefully kill (sigkill). Also doesn’t handle other signals. Gets quite complex to implement.
Could you try try replace please sudo with exec sudo. Then sandbox-app-launcher would be gone. It doesn’t need to do anything after application exited. The executed application would become tty controlling application and process signals (sigterm / ctrl + c; etc.) as if it was started directly.
Quote:
execis a builtin command of the Bash shell. It allows you to execute a command that completely replaces the current process. The current shell process is destroyed, and entirely replaced by the command you specify.
Or do you suppose a feature for sandbox-app-launcher which helps with termination and enforces application is really gone?
That didn’t change anything.
I want the applications to die when sandbox-app-launcher does. It’s annoying having tons of left-over processes.
I just remembered bubblewrap has a --die-with-parent flag which does this. When bubblewrap’s parent (sandbox-app-launcher) dies, it kills everything in the sandbox although it does this with sigkill rather than sigterm which may be problematic.
I think it’d be good to simplify the seccomp filter and create a script that auto-creates the program to generate the filter.
I’ve started working on this.
Script: Debian paste error
New whitelist: Debian paste error
To filter arguments, you need to specify the argument number (currently only 0-2 but that’s trivially expanded) then the actual argument, e.g.:
socket 0 AF_INET
The whitelist will now be much easier to fix, audit, expand, etc.
What do you think?
So it should be debian/sandbox-app-launcher.postrm containing this?
#!/bin/bash
## Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.
if [ -f /usr/lib/helper-scripts/pre.bsh ]; then
source /usr/lib/helper-scripts/pre.bsh
fi
set -e
true "
#####################################################################
## INFO: BEGIN: $DPKG_MAINTSCRIPT_PACKAGE $DPKG_MAINTSCRIPT_NAME $@
#####################################################################
"
rm -rf /var/cache/sandbox-app-launcher-autogenerated /etc/sandbox-app-launcher
for user in "$(getent passwd | grep "sandbox-" | sed -e 's/:.*//g')"
do
userdel "${user}"
done
true "INFO: debhelper beginning here."
#DEBHELPER#
true "INFO: Done with debhelper."
true "
#####################################################################
## INFO: END : $DPKG_MAINTSCRIPT_PACKAGE $DPKG_MAINTSCRIPT_NAME $@
#####################################################################
"
## Explicitly "exit 0", so eventually trapped errors can be ignored.
exit 0
This would remove everything except app data.
Started working on the permissions prompt: Debian paste error
It supports GUI and CLI.
We still need to figure out how to actually start it though. I think we should create /etc/apt/apt.conf.d/50sandbox-app-launcher with something like:
DPkg::Post-Invoke {"/usr/share/sandbox-app-launcher/setup-permissions "${app}"";};
But I don’t know how we’d get ${app}.
We also need to implement stackable wrappers first.
The seccomp stuff makes what once was a simple script now kinda complex. What’s the worst case if there are bugs in the seccomp or apparmor? “Only” that sandbox is weaker? That wouldn’t be catastrophic to effectively run with brap alone. Or anything worse?
## Needed for apps to setup further sandboxing like Firefox/Chromium.
capability sys_admin,
capability sys_chroot,
capability sys_ptrace,
Maybe this could be a separate apparmor abstraction only to be included for wx?
sed -e ‘s/:.*//g’
Can you port to str_replace please?
Yes, but str_replace please.
usr/bin/sandbox-app-launcher: mv "${auto_dir}/seccomp-filter.c" "${auto_dir}/seccomp.c"
usr/bin/sandbox-app-launcher: mv "${auto_dir}/seccomp-filter.c" "${auto_dir}/seccomp-wx.c"
How’s ${auto_dir}/seccomp-filter.c created?
That is a bit difficult to follow in the code flow.
cat < “${seccomp_filter_path}.c”
Perhaps add some comments?
syntax of autogen-seccomp should be
autogen-seccomp path/to/seccomp-whitelist path/to/output-file
?
Or have autogen-seccomp echo to stdout and then redirect (>) to file?
"${auto_dir}/seccomp"
"${auto_dir}/seccomp-wx"
Why does it get executed? Also seems to compile and execute both every time? Could use a comment.
Please do not add /etc/sandbox-app-launcher as that’s the task for apt purge.
Yes, good for testing/cleanup purposes.
It is good to have the prompt separated from actual potential future apt integration.
When run by apt, most likely apt won’t “know” that X is running. After sudo, environment variables are scrubbed. And when apt runs dpkg, environment variables might be scrubbed again. (Unless running apt with sudo var=content apt ....)
By looking at /usr/share/applications/*.desktop files perhaps?
But covers “mostly” graphical applications.
There is also some “other” stuff there.
(example /usr/share/applications/okularApplication_fax.desktop)
That wouldn’t cover any CLI applications worth covering.
But that could easily end in usability disaster.
apt purgeed, it’s corresponding sandbox config is wiped too?Yes, that is blocking many things.
Also to consider server/headless configuration. When DEBIAN_FRONTEND="noninteractive" is set, no questions can be asked.
Perhaps also “ask on first use” is an option? [not necessarily a replacement for “ask at installation time” - just in case it could not be asked during installation]
But this has potential to break things too. When applications are started by programs or scripts during boot and expect behave normally, non-interactive while a stackable wrapper would result in prepending sandboy-app-launcher, which then would result in interactive questions. Perhaps it’s possible to reliably detect if started automatically by program or script or manually by user. Such as if no terminal is connected and no DISPLAY environment variable set, probably safe to assume should not ask interactive questions.
What’s the scope for sandbox-app-launcher? Can we sandbox “low level”, general tools such as /bin/sed, /usr/bin/awk generally by default? Probably not since their use is very versatile. These are probably good targets:
ls etc/sandbox-app-launcher/
chromium.conf hexchat.conf libreoffice.conf onionshare.conf ristretto.conf vlc.conf
firefox.conf keepassxc.conf mousepad.conf qtox.conf thunderbird.conf xpdf.conf
Since these are “high level”, user centrist, end-user applications.
If mousepad is sandboxed, can it still be used to edit files in /etc? It shouldn’t interfere with sudoedit?
I don’t know what you mean.
It’s not relevant to wx so it doesn’t really make sense. You can have sandboxing without needing to violate W^X.
Does str_replace support wildcards? I thought it just replaced strings exactly.
It’s created by autogen-seccomp.
Both good ideas.
Those are the programs that when executed, create the actual seccomp filter (seccomp-filter{,-wx}.bpf).
Then any config file the user makes themselves (or is automatically made by our future script) will be kept.
That’s not a big issue. There’s other ways to detect for X than $DISPLAY e.g.
if ! xset q &>/dev/null; then
That would be a good idea. We could pre-configure as much as possible and check /usr/share/applications/*.desktop which should hopefully cover most. Although it definitely isn’t perfect, it might be good enough for now.
That seems more complicated.
That wouldn’t really make sense. Would be best to sandbox more “high level” things e.g. a browser, an entire shell, etc.
No, that’s read-only. We’d need to separate privileged (unsandboxed) and unprivileged (sandboxed) editing. sudoedit could probably do that.
What if we just grant all permissions when noninteractive and don’t prompt anything?
if [ "${DEBIAN_FRONTEND}" = "noninteractive" ]; then
allow_net=yes
allow_webcam=yes
allow_mic=yes
shared_storage=read-write
allow_dynamic_native_code_exec=yes
fi
Also, we should make a GUI for editing permissions after their initial configuration. Something like Flatseal would be nice GitHub - tchx84/Flatseal: Manage Flatpak permissions
Indeed. That would be the correct thing to do as per Debian policy, I think.
sudo touch /etc/tor/test
sudo apt purge tor
Purging configuration files for tor (0.4.3.5-1~d10.buster+1) …
dpkg: warning: while removing tor, directory ‘/etc/tor’ not empty so not removed
apt remove would not be enough to remove all user generated configs. Perhaps apt purge implies that permission. Then the debian/sandbox-app-launcher.postrm script could do that.
Was also wondering if a .d folder for user overrides would make sense but I guess that is easy to add at a later point.
APT also runs in its own native sandbox?
security-misc /etc/apt/apt.conf.d/40sandbox
## https://forums.whonix.org/t/apt-seccomp-bpf-sandboxing/7702
APT::Sandbox::Seccomp "true";
That might interfere?
How would it know if APT is run from a virtual terminal (tty1) while X server is running in usual tty7?
Right. These .desktop files have a lot fields / meta data which can be used to know if it is sensible to ask or not.
A dpkg trigger watching /usr/share/applications/ could be used as a hook to start asking questions. Triggers example:
Is an option. This could be echo’d. Then anyone reading output of APT would at least know that’s happening.
But what’s the point to say yes for all anyhow? Shouldn’t sandbox-app-launcher in that case simply assume yes for all anyhow? Is the point to have a pre-configured config file for he user so the user can flip settings using sudoedit?
Btw sandbox-app-launcher needs to not break (handle that case explicitly somehow, even if an error message and error exit code)
yyes)