System-wide sandboxing framework - sandbox-app-launcher

I don’t think we should use /home. These aren’t actual user home directories but app sandboxes.

That’d be alright.

Yes, that’s the point. Only the root, nobody and sandbox users/groups are shown in the sandbox.

No, seccomp has to be done with file descriptors. There’s no other way.

FDs are commonly used with bubblewrap. e.g.



I doubt it’s a security risk. If it was, there wouldn’t be so many options requiring FDs in bubblewrap (see bwrap --help).

1 Like

Ok. Please at least get rid of the subshell.

And ideally also get rid of bash -c.

Otherwise please provide the manual command that works how to invoke bwrap as a script comment or here so I can have a look. If brwap manual invocation works (which must work) then I am pretty sure it can be scripted without bash -c.

1 Like

It’s the same as in the script. Just copy/paste it without the bash -c part and run it in your shell.

1 Like
1 Like
1 Like

Some apps (such as ristretto) are dying due to a lack of D-Bus and many more (such as hexchat) are giving off errors. I think we need to figure out how to start a D-Bus session bus for the sandbox users. Maybe via some systemd stuff. I couldn’t figure out how.

1 Like
1 Like

What other apps should I add?

1 Like

This should work but I don’t have access to a webcam or microphone currently to test this. Can someone else test it?

1 Like
1 Like

https://github.com/Whonix/sandbox-app-launcher/pull/16 shouldn’t be merged yet. It breaks some apps using X11. More of a reason to switch to Wayland.

1 Like

/shared is not a good folder location as this breaks FHS. Thereby the package gets unfit for inclusion in most distributions. It’s a new folder that is easily forgotten during backups.

It’s a question what do we optimize for?

Principle of least astonishment (POLA) is a good one.

Follow FHS? That’s a good one too.

Optimize for usability? Not necessarily an optimization problem.

Reading FHS again chapter /home. Relevant quotes…


/home is a fairly standard concept, but it is clearly a site-specific filesystem. [6]

[6] Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for user home directories.

On smaller systems, each user’s home directory is typically implemented as a subdirectory directly under /home , for example /home/smith , /home/torvalds , /home/operator , etc.

On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff , /home/guests , /home/students , etc.

I guess the sandbox use case is closest to “large systems” use case.

/home/sandbox seems appropriate.

  • /home/sandbox/sandbox-${app_name}

(Maybe sandbox- is superfluous. [1])

Therefore advise can stay “backup your home folder”. Meaning not /home/user but meaning backup /home.

That seems to be close to FHS and also be good for usability. Better than /var/lib/sandbox which is a lot harder to remember and backup. Contents of /home are more easily discovered than /var/lib.

Also /home/sandbox/shared or something would be good. But then we must make sure that no app can be named “shared”. [1]

Thinking for restricting user user, could a compromised user user mess with app_name and make an app that shouldn’t access another apps data?

1 Like

/home/sandbox is too generic so I went with /home/sandbox-app-launcher-appdata. Messing with /home/sandbox-app-launcher-appdata/shared isn’t very usable. /shared is far shorter to type and easier to remember. Shared storage is something that users will likely use often (unlike the autogenerated/home directories) so it needs to be more usable.

I don’t really see much issue with /shared. We don’t need to go all out following FHS. Even popular software like Flatpak has /app.

No. I don’t see how they could do that. app_name is only executed under the sandbox. If a user messed with app_name, they’d just create another sandbox.

Aren’t the quotes around $(...) enough? Wouldn’t quoting those variables cancel those quotes?

Is there any reason why using bash -e as a shebang isn’t used at all in Whonix instead of set -e?

1 Like

ERROR: Could not find ‘test test’ in $PATH.

Is there any need for sanitizing app_name when we have the $PATH check?

shellcheck says it’s bad.

^-- SC2086: Double quote to prevent globbing and word splitting.

And it’s true.


set -x

newtest="$(type -P ${testvar})"

This example globs all of /sbin/*

Kinda separate discussion. Not sure if strong reasons but yes.

  • When running bash -x scriptname then the shebang bash -e (errexit) is being disregarded.
  • Stylistic. Imo easier to read. Specifically when using multiple shell options.
1 Like
. "/etc/sandbox-app-launcher/${app_name}.conf"

Currently run before ${app_name} is sanitized. Could you fix that please?

1 Like
  if ! [ -e "${app_path}" ]; then
    echo "ERROR: Could not find '${app_name}' in \$PATH."
    exit 1

It’s not really checking if it’s in $PATH. It checks existence of any file system object (not only file, that’s -f?). Maybe -x?

But then also begging the fundamental question, why should sandbox-app-launcher be limited to binaries in $PATH? Why not any executable whether in $PATH or not in $PATH? The user can execute it anyhow. If with or without sandbox, then the latter is better, no? Maybe I am missing something here still.

1 Like

What about command line parameters to apps cat /path/to/file? Could you please compare with other wrappers (such as uwt) for proper getting name of binary and passing parameters?

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]