Learn SELinux - Sandbox & seunshare

#Introduction

After making sure in episode 18 that SELinux isn't a performance burden, it's time to use SELinux as an active isolation tool for programs that can't be fully trusted. In this episode we unpack two tools designed specifically for that: sandbox and seunshare. You'll learn to run applications — including GUI applications — inside an isolated sandbox, understand the namespaces working behind it, and follow up on two CVEs you must know before using seunshare in production.

#Main Discussion

#Why Do We Need a Sandbox

A simple analogy: you don't place a stranger in the living room and leave the keys to every room on the table. You place them in a separate room, with the door locked, and only that room can they access. An SELinux-based sandbox does the same for programs: the process runs in a new domain that can only access the resources it's allowed to — and every denial is recorded by the same policy you've been learning throughout this series.

What distinguishes a sandbox from simply running a process with a restricted user: a restricted user still inherits that user's context. The sandbox_t domain is a truly different world — with its own /tmp, its own home directory, and (if requested) its own network.

#sandbox: A Ready-to-Use Sandbox

The sandbox tool (from the policycoreutils-sandbox package) wraps all that complexity into a single command. The most common form is running a GUI application like Firefox inside an X11 sandbox:

sandbox -X firefox

The -X option ensures the application can't peek at or press buttons in other applications' windows: the sandbox provides an isolated X display. For further isolation — its own home directory and /tmp on tmpfs:

sandbox -H -T -X libreoffice

sandbox -M -T bash untrusted-script.sh

The most-used options table:

The sandbox command requires the sandbox policy module to be installed — on distros with the targeted policy (RHEL, Fedora, and their derivatives) this is the default. If not, install it with semodule -i sandbox.pp.

#seunshare: Namespace and Policy in One Command

seunshare is the engine behind sandbox. It runs a command inside a new namespace (mount, home, network, and X11) while applying a specific SELinux type. Interestingly, seunshare doesn't require extra policy — a type like sandbox_t is already enough. Direct usage looks like this:

seunshare -t sandbox_t -T /tmp -H /home/alice/sandbox-home -X firefox

Option explanations:

• -t sandbox_t — the SELinux type applied.
• -T /tmp — the temp directory used (ideally tmpfs so it's automatically clean).
• -H /home/alice/sandbox-home — the isolated home directory.
• -X — X11 mode.

The value of seunshare is in the composition: you can combine Linux namespaces with an SELinux domain explicitly, which is hard to achieve with just unshare or just the policy.

#Security Notes: CVE-2026-59676 and CVE-2026-59677

Before using seunshare anywhere, there are two CVEs you must know:

rpm -q libselinux

dpkg -l libselinux1 | tail -1

Upgrade to 3.11 or newer. We'll dissect the 3.11 release in detail in episode 21, including how these vulnerabilities made it into the userspace security fix list. For now just know: never run seunshare version 3.10 in production.

#Don't Set the Setuid Bit Without Need

One detail is often overlooked: for unprivileged users to create namespaces, the seunshare binary needs to run with root setuid. Check the setuid bit on your binary:

ls -l /usr/bin/seunshare

The output for a setuid binary is -rwsr-xr-x (an s in the owner execute position). If you don't actually run sandbox or seunshare with regular users — for example it's only used by admins — consider removing that bit:

chmod u-s /usr/bin/seunshare

#Safe Sandbox Practices

A few rules that keep the sandbox a defensive tool, not a source of problems:

1. Don't mix the real home with the sandbox home. Always give -H a dedicated directory; data from sandboxed processes is considered "possibly contaminated".
2. Use tmpfs for -T. Auto-cleaned temp prevents litter and data leaks.
3. Combine with a network namespace (-N on sandbox, or network settings on seunshare) when the app doesn't need the internet.
4. Update the userspace regularly. CVEs like CVE-2026-59676/59677 just disappear after an upgrade — take advantage of the annual 3.11, 3.12 releases, and so on.
5. Audit denials from sandboxed processes. If a process inside the sandbox starts being denied something unexpected, check with ausearch -m avc as you learned in episode 15.

#Closing

In this episode 19, you've learned that SELinux isn't just about hardening trusted systems, but also about confining untrusted programs: sandbox -X for GUI apps, seunshare for explicit namespace control, plus critical knowledge about CVE-2026-59676 and CVE-2026-59677 and setuid discipline. With a sandbox, a "safe path" for questionable code is no longer impossible — just one command with documented isolation.

In the next episode 20, we step up to the operational level: managing all policies, modules, and SELinux configurations as code — versioned in git, tested in CI, and distributed with Ansible. That's the foundation that makes SELinux usable in large-scale infrastructure, not just on a single server. See you there!