Oz sandbox technical details

Oz sandbox technical details

0 × 01 Introduction

The OZ system protects the program security by running the Linux desktop program in an isolated security sandbox, so that attackers can easily exploit the vulnerabilities of the application to further attack the system.

???? No large and complex desktop program can ensure that no security vulnerability exists. As long as the software can process untrusted or malicious data, this program may become the target of attackers.

???? Applications connected to network services obtain data from the network through network protocols, which may be exposed to malicious data accidentally.

?? For example, the following three types of applications are easily exposed to malicious data:

1. browser 2. Mail Client 3. Instant Messaging Software

Even if an application never connects to the network, it may be attacked as long as it processes data from non-source sources. For example:

1. Document Reader 2. video playback software 3. File Management Software

In a system, especially a single-user system, application destruction is a major problem. If attackers want to monitor a target and obtain its data and further obtain the user permissions of the target terminal, these vulnerabilities are sufficient to achieve this purpose. Through these methods, attackers can obtain data, certificates for logging on to other systems, and local encryption keys. If it is a modern operating system or peripheral hardware, the situation is even more terrible.

The danger of an application on the terminal means that attackers can do the following:

1. user data can be obtained without elevation of permissions, such as documents and email information. obtain the saved information, such as email/instant messaging/website password, encryption key, and system authentication file. modify the user's login properties so that the user can run the modified client without knowing it. 4. obtains and controls the hardware devices used by users, such as mobile hard disks, system recording and video recording devices.

In addition, with the permissions of local users, attackers can also escalate their permissions in many ways:

1. Use the kernel vulnerability or common vulnerability in the binary file. 2. Use a non-privileged backdoor to install a backdoor on the system.

Gradually increasing to administrator permissions will help future attacks: You can obtain control permissions of the entire system and maintain stable remote access, obtain long-term monitoring and avoid being detected by some highly secure systems (although most targets do not have such a high level of security in actual environments, in addition, attackers can control the target for a long time without being detected, although the attacker's permissions are not very high ).

0 × 02 How Does Oz work?

Oz isolates high-risk applications in an isolation layer, so that it can methodically cut off the way to improve permissions and isolate the program and program running data. The purpose of this design is to control these items more precisely and flexibly.

Key features of Oz

The access control parameters of the application in the sandbox are pre-defined in the Oz policy file. Oz has designed many pre-configured policies for special applications.

After installing Oz:

1. The application in the sandbox will be renamed by Oz, and a link will be created at the original binary location in the file system, pointing to the Oz binary file. 2. When the user runs in the original location of the application, Oz starts to work. Oz first checks the application name and then opens the relevant policy file. The policy file contains various parameters to control the running time and environment of the application and how to start the program. 3. Then the Oz daemon will create an isolated environment and put the actual program into the sandbox to set and run the application according to the defined security policy. 4. When the program is running, you can use the Oz CLI tool to open the shell Running in the sandbox container for operations.

 

 

The specific operation process is as follows:

1) when the user runs the application

The application's binary file (/usr/bin/evince in the figure) is a symbolic link to the oz command line tool.

2) The Oz program sends a signal to the Oz background process, telling the background process to put the program into the sandbox.

When the Oz program reads the argv [0] parameter when running the command, oz can know the path of the program to be run and send a message to the oz background process through socket, the program to be run will be started in the sandbox.

3) The oz background process loads the application's policy configuration file

The application configuration file details how to create a sandbox for the Application

4) The Sandbox of the application starts to run.

How to run sandbox

5) A new PID namespace will be created for the oz-init process, such as pid 1

The Oz-init process is used to manage sub-processes in the sandbox. As shown in the preceding figure, Oz-init starts to run the binary file of the application software that is encapsulated by seccomp-bpf on the xupa server. The seccomp-bpf package can constrain the system commands called by the application.

6) There is an xupa client outside the sandbox that is connected to the HPA server in the sandbox.

Xupa isolates the application from the graphic interface server (X server). Therefore, the sandbox cannot capture keyboard records or interfere with the running of other desktop programs.

7) connecting xupa to the real graphics interface server

The xupa client displays the application window in X server.

0 × 03 security objectives

Prevent access to data that exceeds the required data

Oz creates a new space that is isolated from the file system of the physical machine and stores the application to be run in the root directory of the isolation zone. The Oz application policy configuration file defines the whitelist and blacklist to control files and directories that can be accessed and cannot be accessed during running.

For example, an application in Oz may not be able to access the following files unless necessary:

1. SSH key of the user 2. Mail content of the user 3. encryption key of the user 4. Document Information of the user 5. Download file 6. User identification file of the system

Many static access control permission systems, such as AppArmor or SELinux, cannot completely solve this problem because a single policy needs to be defined with sufficient permissions, in this way, the program can run normally in a complex environment.

One of the most descriptive examples is the document reading software evince, which usually requires read/write permissions for any directory in the file system. You can run evince and load any files they want to view from the menu.

However, when we use evince to open an untrusted document, this policy seems inappropriate because it may contain malicious code to attack the reader itself. What we need is that even if a user opens a threatening document, the reader cannot allow attackers to read or erase other data that does not belong to the user.

In Oz, when you use evince to read a document, the sandbox file system does not load any user data except for the document data. Such access permissions (only a single document needs to be read in the sandbox) dynamically determine the data to be loaded from user behavior.

Attackers can execute arbitrary code.

What attacks can be achieved depends on what vulnerabilities are first exploited. If the memory-damaged vulnerabilities are exploited, attackers can exploit this vulnerability to execute arbitrary machine code (the system will be injected and attacked by attackers, or the memory address space will be cleared, the only thing that can restrict this behavior is access to the kernel facility.

Another arbitrary execution vulnerability allows attackers to run executable files in the file system, and then increase their permissions to control the entire operating system. To prevent attackers from executing arbitrary code, the file system must be set to be unable to execute any code from any writable directory. In addition, the script interpreter should be within the restricted range.

Reduce kernel exposure resulting in Elevation of Privilege

Attackers may attack the operating system kernel by calling system commands, devices, or kernel file systems (such as/proc) to bypass the sandbox environment.

The application must be filtered by Seccomp-BPF when running. These filters reduce kernel-level attacks by limiting the number of system calls of processes. Linux Kernel vulnerabilities can lead to elevation of permissions, which can be seen when system commands are called. Reducing the number of exposed system commands reduces the number of code paths and discovers kernel vulnerabilities.

Prevent attackers from gradually improving system Permissions

The namespaces used in the Oz system isolate various operations that interact with the background processes of the system, because these operations may be exploited by hackers.

 

Prevent Attacks by setting user tokens or enhancing binary file performance

When the program is running in the sandbox, a flag PR_SET_NO_NEW_PRIVS is used to avoid obtaining any function. In addition, all file systems running in the sandbox are installed with MS_NOSUID and the existing binary files with user identifiers are blacklisted.

Restrict network access to avoid user data leakage

Oz creates a network namespace in each Oz container, which includes the Oz Virtual Interface. The policy can be used to determine how Oz communicates with external networks. If the application does not need to connect to the network, the program can be completely denied to connect to the network.

For example, the image display software does not need to connect to the network, and the namespace it runs in the sandbox does not contain any network devices, while other applications, for example, an IM client only needs a simple access address and port, which requires minimal network access.

Isolate X window applications

X The structure of Windows poses a challenge to the sandbox security of Linux Desktop programs. Any process connected to X server can capture users' keyboard input and any screen processed in the desktop window. The Oz quarantine program connects the private X servers of each sandbox to the real X server through xupa.

Minimize sandbox Exposure Devices

Each application's container environment has a/dev, which is equipped with the minimal device required for running the program.

The installed devices (such as mobile hard drives) in the sandbox environment will be exposed as little as possible, and the audio and video storage will also be controlled by the Oz policy.

0 × 04 specific operations

File System

The following describes how to operate the sandbox file system.

1. Create a New rootfs directory

rootfs = "/srv/oz/rootfs"mkdir(rootfs)

2. recursively set the MS_PRIVATE Value

mount("", "/", "", MS_PRIVATE | MS_REC, "")

Because this is in a new installation space, it only affects the oz-daemon process
3. Add tmpfs to the rootfs directory

mount("", rootfs, "tmpfs", MS_NOSUID | MS_NOEXEC | MS_NODEV, "mode=755,gid=0")

4. Bind/bin/lib/lib64/usr/etc

mount("/bin", "/srv/oz/rootfs/bin", "", MS_BIND, "")mount("", "/srv/oz/rootfs/bin", "", MS_REMOUNT | MS_RDONLY)// repeat for remaining directories

5. Create an empty directory

var basicEmptyDirs = []string{    "/sbin", "/var", "/var/lib",    "/var/cache", "/home", "/boot",    "/tmp", "/run", "/run/user",    "/run/lock", "/root",    "/opt", "/srv", "/dev", "/proc",    "/sys", "/mnt", "/media",}

6. Install tmpfs in/srv/oz/rootfs/dev.

mount("", "/srv/oz/rootfs/dev", "tmpfs", MS_NOSUID | MS_NOEXEC, "mode=755")

7. Create a device

crw-------. 1 root root 5, 1 Jun 28 17:18 consolecrw-rw-rw-. 1 root root 1, 7 Jun 28 17:18 fullcrw-rw-rw-. 1 root root 1, 3 Jun 28 17:18 nullcrw-rw-rw-. 1 root root 1, 8 Jun 28 17:18 randomcrw-rw-rw-. 1 root root 5, 0 Jun 28 17:18 tty-rw-r-----. 1 root root    0 Jun 28 17:18 tty1-rw-r-----. 1 root root    0 Jun 28 17:18 tty2-rw-r-----. 1 root root    0 Jun 28 17:18 tty3-rw-r-----. 1 root root    0 Jun 28 17:18 tty4crw-rw-rw-. 1 root root 1, 9 Jun 28 17:18 urandomcrw-rw-rw-. 1 root root 1, 5 Jun 28 17:18 zero

8. Create a symbolic connection

var basicSymlinks = [][2]string{  {"/run", "/var/run"},  {"/tmp", "/var/tmp"},  {"/run/lock", "/var/lock"},  {"/dev/shm", "/run/shm"},}var deviceSymlinks = [][2]string{  {"/proc/self/fd", "/dev/fd"},  {"/proc/self/fd/2", "/dev/stderr"},  {"/proc/self/fd/0", "/dev/stdin"},  {"/proc/self/fd/1", "/dev/stdout"},  {"/dev/pts/ptmx", "/dev/ptmx"},}

9. Create a blacklist file or directory

dr-x------.   2 root root     40 Jun 28 17:18 oz.ro.dir-r--------.   1 root root      0 Jun 28 17:18 oz.ro.file

10. Blacklist specific directories

var basicBlacklist = []string{  "${PATH}/sudo", "${PATH}/su",  "${PATH}/xinput", "${PATH}/strace",  "${PATH}/mount", "${PATH}/umount",  "${PATH}/fusermount",}

11. Bind a whitelist from the interface

The interface whitelist option is added to the sandbox by clicking a file or directory event.

12. If xupa is used, create the xupa socket directory in the user directory and bind it to the sandbox.

[evince] $ ls -n $HOME/.Xoz/evince/evince-0srw-------. 1 1000 1000 0 Jun 28 17:18 /home/x/.Xoz/evince/evince-0

1. Go to chroot

chroot("/srv/oz/rootfs")chdir("/")

2. Add the Kernel File System to the sandbox

mount("", "/dev/shm", "tmpfs", MS_NOSUID | MS_NOEXEC | MS_NODEV)mount("", "/tmp", "tmpfs", MS_NOSUID | MS_NOEXEC | MS_NODEV)mount("", "/dev/pts", "devpts", MS_NOSUID | MS_NOEXEC "newinstance,ptmxmode=0666")mount("", "/proc", "proc", MS_NOSUID | MS_NOEXEC)mount("", "/sys", "sysfs", MS_NOSUID | MS_NOEXEC | MS_RDONLY)

Network Diagram

Bridged Networking)

If your application needs to communicate with the network, the sandbox will create a private network for the application, and the network is connected to the external network through bridging.

No network)

If an application does not need to access the network, No network is created in the network namespace of the sandbox.

Proxy networking)

If you already know that an application only needs to connect to some special services when it is started, the local proxy listener will be configured, it is used to listen when a program is connected to a remote address or port. In this case, except for specific services, other online services do not need to be configured and run.

Seccomp

If attackers have local or some non-specific permissions, the kernel vulnerability will be a very effective way to escalate permissions. Many kernel vulnerabilities expose the entire process of program running to attackers through system calls. There are often too many system calls that are not necessary for program running, attackers can exploit these calls to launch vulnerability attacks.

Seccomp filtering is a Linux kernel calling mechanism provided by Oz that can reduce kernel-level attacks. It can be filtered by limiting the number of processes called by the system and controlling the use of determined system calls. In Oz, each application has Seccomp rules. These rules specify system calls in the whitelist and system calls in the blacklist. These calls will be run immediately before the program runs. In this way, if the program has a kernel vulnerability, such a mechanism can limit attackers to further extract SYSTEM privileges.

Related videos

The following is an operation video of two Oz sandboxes:

Demo vid 1: https://support.subgraph.com/videos/oz_evince_01.webm

Demo vid 2: https://support.subgraph.com/videos/ozshell_evince_01.webm

X server is the abbreviation of the graphic interface server in Linux. To sum up the hierarchical relationship between the graphic interfaces of linux: linux itself-> X server <-[talk through X protocol]-> Window Manager (integrated desktop environment)-> X application.