System-wide sandboxing framework - sandbox-app-launcher

gimp as bonus


I can implement a system similar to android permissions into this.




Then we can do something like:

. "/etc/sandbox-app-launcher/${app_name}.conf"

## Deny network access.
if [ "${allow_net}" = "no" ]; then

## Deny microphone access.

What do you think?

The default should be allow all so apps don’t break but users can restrict the permissions more if they want to. Or, we could have a popup upon installation that is something like:

zenity --list --text "What permissions do you want to grant to this application?" --radiolist --column "Pick" --column "Answer" FALSE "Network access" FALSE "Microphone access" FALSE "Webcam access" FALSE "All"

but allows selecting more than one.

It would also be nice to detect if the app tries to access something then give a popup asking if you want to give the app that permission but I wouldn’t know how to implement this.

1 Like

This is hard. Re-implementing something similar to what Android does. The user interface needs to be to show elements (security question) which cannot be faked by the application. I.e. if a malicious application would overwhelm the user with questions in order to trick the user into giving an additional permission.

This is good since it breaks down difficult syntax into more human readonable configs.

How would any application use that?
Stackable Wrappers issue?

Popup during installation of what? Package? That won’t be good. There are no packages which use a GUI to ask questions. Please also keep headless systems in mind (even if just skipping any questions there). Also asking the user security questions is mostly a bad idea. I guess we’d have to pre-configure this for some applications?

What about new applications? How would sandbox-app-launcher notice that there’s a new package (or even binary/appimage in user home folder) and then ask the user security questions? Not necessarily an issue you need to solve. I guess the user needs to be aware of sandbox-app-launcher and wanting to use it manually?

Also GUI applications shouldn’t be writing files into /etc. None of packages from do that.

1 Like

I’m not sure what you mean. The sandbox script would source the config file and set the needed arguments. Applications aren’t meant to use it.


I don’t think it’s that bad. Headless systems aren’t an issue, we can’t just use read. These aren’t going to be complex security questions. I think most ordinary users would know if they want the program to access their microphone or not. It works fine in android. Pre-configuring it isn’t the best as we can’t configure all applications so most will still have all permissions.

I’m not sure how to solve this yet.

See the original post:

I’m not sure how we’re going to choose which apps to sandbox. Maybe via packages’ Section: ?

Maybe we can create an apt hook that sets up the sandbox during package installation? We can probably choose all packages that have a certain Section: rule so things like administration utilities won’t be sandboxed.

As for binaries in the user’s home folder, it would be best if we kill those off entirely via TPE or apparmor-profile-everything. Allowing execution of arbitrary code is a major issue. I’ve fixed this in the sandbox via W^X and apparmor but it doesn’t account for outside of the app sandbox.

We do need to solve this. Every app should be sandboxed so we have a strong default security model. It only takes 1 unsandboxed app to access all user data.

1 Like

Also, on W^X, it can break some programs (such as browsers for JIT) so we’d need to have a whitelist

There shouldn’t be too many programs with writable and executable memory mappings nowadays anyway.

PaX’s MPROTECT implemented this and had a way to whitelist programs from the restrictions so there exists some userspace daemons with whitelists we can look at such as paxd-archive/paxd.conf at master · thestinger/paxd-archive · GitHub

Suggestions are welcome, especially for more permissions.

I can’t implement the webcam/mic permissions as I wouldn’t know how, but it’d likely involve bind mounting the webcam/mic device nodes.

To ask another way: User types xchat in xfce4-terminal emulator or starts xchat through xfce start menu. Why would xchat start sandboxed rather than non-sandboxed?

If asking during apt installation, at least those applications that are pre-installed would need to be pre-configured. Otherwise build process would move from non-interactive to interactive.

There are many different scenarios.

  • application gets installed during build / inside chroot, in that case any interactiveness is very unwanted
  • non-interactive / automated upgrades
  • upgrades in terminal emulator but then apt runs as root or even limited user - how to sanely start a GUI from there? Even if working, likely breaking with wayland. (That’s what msgcollector is doing. Applications can create files which will be watched by msgdispatcher which runs as user “user” which then shows these messages.)
  • upgrade from a virtual terminal (but then apt stopping in the middle to ask questions where one needs to type is also inconvenient)

Debian has debconf for that.

But really best avoided. Packages that ask questions during installation are a major source of user confusion.

Android as a good user interface. It doesn’t ask questions during installation or upgrade of apps or for any pre-installed applications. It asks when the application is started for the first time which seems a lot better.

Various cases:

  • application is started from graphical environment, example xfce start menu or desktop icon
  • application is started from graphical environment terminal emulator with X available
  • application is started from virtual terminal
  • application is started by another application (cron, nginx, sdwdate, etc. start some application in background)
  • anything else?

How to distinguish these cases from a script level? It may be possible to detect / handle all these cases. Just showing that it’s non-trivial.

Is there any similar application that can handle all these cases already so we don’t have to re-invent it in a way that is overlooking use cases?

This stuff is easier for Android since they have only 1 case: manual use by user with GUI.


We’d have to use the stackable wrappers.

Those should be pre-configured.

Upgrades wouldn’t trigger this. Only on package installation.

You mean how can other users connect to the X server?

We can use xhost i.e. xhost +SI:localuser:root.

Again, it’d only be triggered by installing the package, not by updates.

That seems a lot more complex than asking upon installation.

[1] Stackable wrappers concept only covers applications where their part if known at the time when the stackable wrapper is written. It cannot wrap applications which aren’t defined by path.

On apt level there is not much distinction between install and upgrade. dist-upgrade can result in installation of new packages when dependencies changed.

Shouldn’t run applications under root.

Safely Use Root Commands

One thing is to be logged in as user and then use sudo --set-home, lxsudo or pkexec to get root in a sane way. But running under the root user and then starting a GUI application can lead to permission issues.

Same unsolved issue, same complexity as [1].

dist-upgrade (which includes both upgrade and install) can be run from a virtual terminal - no GUI. Also also without any option for any user input. These cases need to be handled as well. Unless we do something similar style as Android: say GUI support only.

1 Like

This might require a Linux LSM and/or hook for Linux kernel hook execve. Usermodehelper? Otherwise I wouldn’t know any call to any arbiary binary could be checked provided by a package of some section to then be wrapped so it could be sandboxed. …which would make all of this really complex and also add attack surface if done wrong. This could use input from other clever people. Could you please discuss this with other (Debian based) Linux distributions which could be interested too in such a sandboxing framework for wider input on how to best implement this?

1 Like

I really don’t think we need to modify the kernel for this. A smart wrapper and apt hook should be fine.

Usermodehelpers are a way for kernel code to execute userspace programs which isn’t relevant to us.

Adding new hooks into the kernel is a really bad idea.

What do you mean by this? Binaries in non-standard directories such as /home or /tmp? We should just kill those off anyway and only allow execution from directories such as /bin.

Or do you mean a user executing /usr/bin/xchat instead of xchat?

Like what?

Parrot OS comes to mind but they’re more about security theater than actual security and the last post about hardening seems to be mostly ignored with nothing actually done.

Yes, I am not eager at all to invent kernel hooks and ship them at Whonix level.

No, I am not considering /home or /tmp here. In other words by comment “It cannot wrap applications which aren’t defined by path.” was about /usr/bin etc.

Using hello as an example. It’s at /usr/bin/hello. How would a wrapper /usr/local/bin/hello (or whatever else wrapper mechanism, this one might not be actually good) be placed in /usr/local/bin/hello if it is unknown at package build time that at a later time there will be a binary /usr/local/bin/hello?

Another example. Let’s say a user installed gajim. Now executes gajim. How you’d intercept that in a generic way to run that through the wrapper instead of just plain gajim?

curl.anondist is a wrapper for curl which. A file shipped in uwt package. But there’s only a limited number of wrappers shipped in uwt package. There’s no wrapper for hello because I wouldn’t know what applications will be installed. Some applications can be covered but not any application that could be installed by the user. That’s what I meant by “aren’t defined by path”.

Kinda. Not necessarily the user runs /usr/bin/xchat instead of xchat. /usr/share/applications/vlc.desktop (the desktop entry) hardcodes Exec=/usr/bin/vlc […]. Similar for other desktop shortcuts. Then also scripts and programs that run commands hardcode the path /usr/bin etc.

Comes to mind, I previously asked solar where to discuss security-misc. Would be OK to discuss on oss-security and solar might have some comments.

I hope Whonix isn’t the only security-focused Linux distribution left.

There’s also tons of Debian people interested in Debian security. They might not be in charge, well organized, etc. but they exist. Tails? Clip OS?


So you mean how do we create wrappers for new programs the user installs which we don’t know about?

That’s what I meant by an apt hook. During installation of a new program, it can create a wrapper for the program.

We can fix those to not hardcode the path.

It might be good to suggest all of our recent work to Tails including security-misc, apparmor-profile-everything, hardened-kernel etc. as well as this.

CLIP OS is based on Gentoo, not Debian and uses a bunch of containers instead so they won’t be interested in this.

madaidan via Whonix Forum:

Get rid of the need for a config file by madaidan · Pull Request #1 · Kicksecure/sandbox-app-launcher · GitHub

Switch to a seccomp whitelist by madaidan · Pull Request #2 · Kicksecure/sandbox-app-launcher · GitHub


Could you please move from using which to command -v? I can’t find
the reference anymore. Might be from Greg Wooledge. Not sure that was
security relevant or best practices. which is an external utility.
command -v is a built-in.

Btw I am documenting such things now:

(Similar to Linux one but a lot simpler.)

Could you please run shellcheck usr/share/sandbox-app-launcher/sandbox? There might be quite a few
false positives.

For example app_path="$(which ${app_name})" I am quite sure variable
app_name should be quoted.

As for sudo -H -u "${app_user}" bash -c " it is true that any quotes
within the already open quote will actually unquote it.

Could you please also copy the other usual files? (Such as from
helper-scripts or most Whonix packages.)

  • GPLv3
  • Makefile

Also a /debian folder template would be good. Can also copy from
helper-scripts and then filename / string replace all mentions of
helper-scripts with sandbox-app-launcher. I’ll then complete the actual

1 Like

usr/share/sandbox-app-launcher/sandbox currently has broken white space handling. It breaks if lib_dir or main_app_dir has a space in its folder or file name.

Proper white space within quotes handling in bash is non-intuitive, non-trivial to figure out but I guess once there’s a working example it should be doable.


Created simplified example here:
/bin/bash Proper Whitespace Handling - Whitespace Safety

Full line then which hopefully won’t fail on white spaces:

sudo -H -u "${app_user}" bash -c '"${cmd[@]}"'
1 Like

Doesn’t seem to be the same.

command -v ls

alias ls=‘ls --color=auto’

type -P would probably be better.

1 Like

Good find. Yes, better.

1 Like
1 Like

Is it possible to get the name of the package being installed from an apt/dpkg hook? Then to automatically setup the sandbox, we can setup something like:

DPkg::Post-Invoke {"echo -e '#!/bin/bash\n/usr/share/sandbox-app-launcher/sandbox $(basename $0)' > /usr/local/bin/${pkgname}; chmod +x /usr/local/bin/${pkgname};};
1 Like