![]() PulseAudio was also not written with isolation in mind so access to it is blacklisted from within the sandbox. Everything else is mounted read-only or as a tmpfs (a file system which keeps all files in virtual memory). 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. The main things that legitimately require this are JIT engines in browsers. Return-oriented programming (ROP) / Jump-Oriented-Programming (JOP) ) which is much more limited and difficult. These mechanisms force attackers to utilize the already existing code (e.g. AppArmor is used to prevent execution of programs from writable directories.Seccomp is used to prevent creation of memory mappings that are both writable and executable and transitioning a writable memory mapping to executable.Enforcing strict W^X in both memory and the filesystem.This is prevented by the following mechanisms: This is safe since each application runs as their own user with their own session bus, ensuring no IPC between sandboxes.ĭynamic native code execution is generally a security issue since it allows an attacker to execute new arbitrary code. This attack vector is mitigated by denying access to the system bus and only allowing access to the session bus. Table: Sandboxed Application Launcher Mitigations Sandbox Escape Vectorĭ-Bus is common avenue for sandbox escapes. Implement W^X (explained in detail further below).Īpparmor also gives fine-grained controls over IPC signals, D-Bus, UNIX sockets, ptrace and more. ![]() 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.In addition, the arguments of some syscalls are filtered to: Seccomp blocks certain syscalls which can greatly reduce kernel attack surface among other things.Īll applications by default use a seccomp whitelist to block dangerous and unused syscalls. Fine-grained filesystem restrictions are implemented via mount namespaces and AppArmor. 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. To learn more, see:īubblewrap allows developers to make use of namespaces and seccomp. The launcher is currently a work-in-progress and is not yet ready for actual use. shared storage access (read-only or read-write) andĪll 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).There are currently five available permissions: This implements a permissions system to configure what applications can access. The directory /shared is shared across all application sandboxes to transfer files across. This launcher is geared towards end-user applications, not any system software. It runs each application as its own user, within a bubblewrap sandbox and confined by AppArmor. Sandbox-app-launcher is an application launcher that can start each application inside its own restrictive sandbox.
0 Comments
Leave a Reply. |