sandbox-app-launcher - Sandboxed Application Launcher

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Protection Against Physical Attacks Documentation Noexec Previous page: Protection Against Physical Attacks Index page: Documentation Next page: Noexec sandbox-app-launcher - Sandboxed Application Launcher

sandbox-app-launcher is an application launcher that starts each app inside its own restrictive sandbox. It runs each app as its own user, in a bubblewrap sandbox and confined by AppArmor.

Warning: This is for developers-only!

Introduction

sandbox-app-launcher is an application launcher that can start each application inside its own restrictive sandbox. It runs each application as its own user, within a bubblewrap sandbox and confined by AppArmor.

This launcher is geared towards end-user applications, not any system software. The directory /shared is shared across all application sandboxes to transfer files across.

This implements a permissions system to configure what applications can access. There are currently five available permissions:

• network access;
• webcam access;
• microphone access;
• shared storage access (read-only or read-write); and
• dynamic native code execution.

All user-installed applications will be automatically configured to run in the sandbox and a prompt will ask which permissions should be granted to the application (not implemented yet).

The launcher is currently a work-in-progress and is not yet ready for actual use. To learn more, see:

• https://github.com/Kicksecure/sandbox-app-launcher
• https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008

Design

Bubblewrap allows developers to make use of namespaces and seccomp. All applications are run in mount, PID, cgroup and UTS namespaces; IPC namespaces are planned but are not currently implemented due to limitations in Xorg. Fine-grained filesystem restrictions are implemented via mount namespaces and AppArmor. Seccomp blocks certain syscalls which can greatly reduce kernel attack surface among other things.

All applications by default use a seccomp whitelist to block dangerous and unused syscalls. In addition, the arguments of some syscalls are filtered to:

• Block unused socket address families.
• Block any dangerous or unused ioctls such as TIOCSTI (can be used in sandbox escapes), TIOCSETD (can increase kernel attack surface by loading vulnerable line disciplines), SIOCGIFHWADDR (can retrieve the user’s MAC address), etc.
• Implement W^X (explained in detail further below).

Apparmor also gives fine-grained controls over IPC signals, D-Bus, UNIX sockets, ptrace and more.

Sandbox Escape Mitigation

Table: Sandboxed Application Launcher Mitigations

Sandbox Escape Vector	Mitigation
D-Bus	D-Bus is common avenue for sandbox escapes. This attack vector is mitigated by denying access to the system bus and only allowing access to the session bus. This is safe since each application runs as their own user with their own session bus, ensuring no IPC between sandboxes.
Dynamic Native Code Execution	Dynamic native code execution is generally a security issue since it allows an attacker to execute new arbitrary code. This is prevented by the following mechanisms: Enforcing strict W^X in both memory and the filesystem. Seccomp is used to prevent creation of memory mappings that are both writable and executable and transitioning a writable memory mapping to executable. AppArmor is used to prevent execution of programs from writable directories. These mechanisms force attackers to utilize the already existing code (e.g. Return-oriented programming (ROP) / Jump-Oriented-Programming (JOP)) which is much more limited and difficult. The main things that legitimately require this are JIT engines in browsers.
Malware Persistence	The only places malware can persist inside the sandbox are the home directory or shared storage (if enabled as read-write) and it can only ever be executed if W^X is disabled. Everything else is mounted read-only or as a tmpfs (a file system which keeps all files in virtual memory).
PulseAudio	PulseAudio was also not written with isolation in mind so access to it is blacklisted from within the sandbox. By default this will break a lot of things so a more robust solution like PipeWire may be used in the future.
Separate User per Sandboxed Application	This approach provides a higher security threshold: Sandboxing programs running as the same user has historically, never seriously worked well. It’s been the cause of many issues with e.g. Flatpak. It’s why Android/iOS have always used separate users.
X11	X11 does not have GUI isolation so it is trivial to escape sandboxes with it. There is no protection against this vector at present, but the plan is to either switch to Wayland or use a nested X11 server like Xpra.

Installation

Install package(s) sandbox-app-launcher following these instructions

1 Platform specific notice.

• Kicksecure: No special notice.
• Kicksecure-Qubes: In Template.

2 Update the package lists and upgrade the system.

sudo apt update && sudo apt full-upgrade

3 Install the sandbox-app-launcher package(s).

Using apt command line --no-install-recommends option is in most cases optional.

sudo apt install --no-install-recommends sandbox-app-launcher

4 Platform specific notice.

• Kicksecure: No special notice.
• Kicksecure-Qubes: Shut down Template and restart App Qubes based on it as per Qubes Template Modification.

5 Done.

The procedure of installing package(s) sandbox-app-launcher is complete.

Usage

Setup

For example, to setup a sandbox for firefox, run.

sudo sandbox-app-launcher setup firefox

Use

For example, to start firefox using sandbox-app-launcher, run.

sandbox-app-launcher start firefox

To show all sand boxes.

sandbox-app-launcher list

To delete user data.

sudo sandbox-app-launcher remove firefox

Development Discussion

https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008

Pros: Can help with multi user. it starts each program under separate user already.

Issues:

• Integration with start menu might be a challenge.
• Also typing "firefox" in xfce terminal circumvents sandbox app launcher and starts it without it. Also hard to enforce.

References

Protection Against Physical Attacks Documentation Noexec Previous page: Protection Against Physical Attacks Index page: Documentation Next page: Noexec

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2025 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!