An application sandbox is a restricted execution environment in which an installed program runs with access only to the resources it has been explicitly granted, such as specific folders, devices, network access or system services. Everything outside that boundary is hidden or denied by the operating system, so a faulty or malicious application cannot freely read user data or change the system.
In the context of software installation and packages, sandboxing is part of how modern package formats deliver applications. Flatpak and Snap on Linux, the App Sandbox on macOS, AppContainer for packaged Windows apps and the mobile platforms all combine packaging with a permission model, so that installing an application also defines what it is allowed to do. On mobile platforms the same mechanism is usually called app sandboxing.
How an application sandbox isolates a program
A sandbox works by placing the process inside boundaries enforced by the kernel, not by the application itself. The program starts with a reduced view of the system and a reduced set of privileges, and every attempt to cross those boundaries is checked against a policy that the package or the user has defined.
The isolation is built from several operating system mechanisms. Each one restricts a different kind of access, and a robust sandbox combines several layers so that a gap in one layer is covered by another. The table lists the most common building blocks.
| Mechanism | What it restricts | Where it is used |
|---|---|---|
| Namespaces | View of files, processes, users and network | Flatpak, Snap, containers on Linux |
| Seccomp filters | Which system calls the process may make | Flatpak, Snap, browsers |
| Mandatory access control | File and service access by policy | AppArmor for Snap, SELinux, macOS sandbox profiles |
| Integrity levels and capabilities | Access to objects outside the container | Windows AppContainer |
| Entitlements | Declared rights checked at launch | macOS and iOS App Sandbox |
A key design element is the broker or portal. Instead of opening any file directly, a sandboxed application asks a trusted system component to show a file chooser. The user picks a file, and only that file is passed into the sandbox. This keeps the application useful while granting access per action rather than in advance.
Permissions and the sandbox policy
Every sandbox needs a policy that defines the allowed resources. In package-based sandboxes the developer declares the needed permissions in the package manifest, and the user or administrator can review, narrow or extend them after installation.
The granularity of permissions matters more than their number. Broad permissions such as full home directory access effectively dissolve the sandbox, while narrow permissions keep it meaningful. The table shows typical permission categories and how risky each one is.
| Permission | Grants | Risk if misused |
|---|---|---|
| Network access | Outbound and inbound connections | Data exfiltration |
| Home directory access | All personal files of the user | Very high, sandbox largely bypassed |
| Specific folder access | One directory such as Downloads | Limited to that folder |
| Device access | Camera, microphone, USB or GPU | Surveillance or hardware misuse |
| Display server access | Drawing windows and reading input | Keylogging under X11 |
| Session bus access | Talking to other desktop services | Escalation through other programs |
On Linux desktops the display protocol is a recurring weak point. Under X11, any client can read the input of other windows, so a sandboxed application with X11 access can observe keystrokes. Wayland isolates clients from each other, which makes Wayland a prerequisite for strong desktop sandboxing.
Sandboxing across package formats and platforms
Application sandboxes differ mainly in whether isolation is mandatory and how strict the defaults are. On mobile platforms, every application is sandboxed with no exception. On desktops, sandboxing is often optional or partial, because users expect programs to reach their files freely.
On Android, every installed app receives its own Linux user ID and a private data directory, while SELinux policies and seccomp filters add mandatory restrictions. On iOS and iPadOS, each app runs in a randomized container directory under a kernel-enforced sandbox profile, and additional capabilities are declared as entitlements signed into the app.
The comparison below covers the formats most often encountered in installation and packaging work.
| Format or platform | Sandbox | Default strictness | Notes |
|---|---|---|---|
| Flatpak | Yes, bubblewrap with portals | Depends on the manifest | Permissions adjustable by the user |
| Snap | Yes, AppArmor and seccomp | Strict confinement by default | Classic confinement disables isolation |
| AppImage | No built-in sandbox | None | Optional external tools such as Firejail |
| MSI installer | No | None | Runs with full user or administrator rights |
| MSIX with AppContainer | Yes | Strict for packaged apps | Capabilities declared in the manifest |
| macOS App Store apps | Yes, App Sandbox | Mandatory | Entitlements reviewed during distribution |
The difference between a sandbox and a container or virtual machine is one of purpose and depth. A container isolates whole services for deployment, and a virtual machine emulates hardware with its own kernel. An application sandbox shares the host kernel and desktop session, which makes it lightweight but dependent on kernel security.
Limitations, trade-offs and common mistakes
A sandbox reduces the damage a compromised program can do, but it does not make the program trustworthy. Any data placed inside the sandbox remains exposed, and a vulnerability in the kernel or in a portal can allow an escape. The decisive principle is least privilege: grant only what the application genuinely needs.
The most frequent problems come from the tension between isolation and usability. Developers often request broad permissions to avoid user complaints, which turns the sandbox into a formality. The following table summarizes typical symptoms and their causes.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Application cannot open a file | Folder outside granted paths | Use the file chooser portal or grant the folder |
| Plugins or themes do not load | Host paths hidden from the sandbox | Install them as extensions of the package |
| Printing or screen sharing fails | Missing portal implementation | Install the desktop portal backend |
| Sandbox offers no real protection | Home directory or X11 access granted | Narrow permissions and prefer Wayland |
| Higher disk use | Bundled runtimes and libraries | Share runtimes across applications |
Administrators should also remember that permissions can be changed after installation. Overrides in Flatpak or connected interfaces in Snap persist across updates, so a permission granted once for troubleshooting may stay active long after it is needed.
On mobile devices, rooting or jailbreaking deliberately weakens the sandbox by granting system-level privileges, which is why banking and enterprise apps often refuse to run on such devices.
In simple terms
An application sandbox is like giving a guest access to one room instead of the whole house. The guest can do everything they came for in that room, but the doors to the other rooms stay locked.
When a sandboxed program wants something outside its room, such as a photo from your folder, it has to ask, and you hand over just that one photo. If the program misbehaves or has been hacked, the damage stays inside its room and your other files remain safe.
A practical example
A university IT department manages several hundred Linux workstations used by students. It installs a web browser, an office suite and a messaging client as Flatpak packages from a central repository instead of as traditional system packages.
Before deployment, the administrators review each manifest and remove the full home directory permission from the messaging client, granting only the Downloads folder. Files elsewhere can still be shared through the file chooser portal, and the workstations run a Wayland session so that applications cannot read keystrokes from other windows.
Later in the semester, a malicious attachment exploits a flaw in the messaging client. The exploit runs, but it sees only the Downloads folder and cannot read SSH keys or course work in other directories. The incident is contained to one application, which the department updates the same day.