Seccomp Policy Development

Overview

Introduction

Secure computing mode (Seccomp) is a security mechanism provided by the Linux kernel. In the Linux system, a large number of system calls can be opened to user-mode programs without any restrictions. However, not all of these system calls are necessarily needed for user-mode programs. In this case, abuse of system calls can lead to system threats. For example, if a process has a security vulnerability, an attacker can run a shellcode segment to trigger system calls that are not triggered during normal execution, resulting in privilege escalation or private information leakage. To prevent such security risks, Seccomp limits the scope of system calls that can be used by programs, so as to reduce system exposure and improve security.

Operating Mechanism

1. Basic mechanism

   Seccomp policies exist in the form of policy files. During compilation and building, a policy file is parsed to generate a source file that contains the BPF instruction policies, and then the source file is compiled into a dynamic policy library. During startup of a user-mode process, Seccomp system calls are invoked to load the BPF instruction policies into the kernel through the dynamic policy library.

2. Basic features

   • A child process inherits the Seccomp policies of its parent process.
   • After a Seccomp policy is loaded to the kernel during process running, the policy exists in the memory as a singly linked list and cannot be modified.
   • Seccomp policies can be set for a process for multiple times. When a process executes a system call, the kernel traverses the policies specified for the nodes in the singly linked list, and then compares the policies to obtain the policy with the highest priority.

Constraints

• System restrictions
  The system used must be a standard system, and the options listed below must be enabled in the kernel. You can find the kernel option configuration file of the product in //kernel/linux/config/{linux_version}/arch/{target_cpu}/configs/.

  CONFIG_HAVE_ARCH_SECCOMP=y
  CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
  CONFIG_SECCOMP=y
  CONFIG_SECCOMP_FILTER=y
  

• Feature restrictions

  • The Seccomp policy for non-privileged processes complies with the baseline blocklist mechanism.
  • If a process needs to use system calls in the baseline blocklist, the system calls must be declared in the privileged process policy file.
  • The same Seccomp policy is enabled for all application processes.
  • The same Seccomp policy is enabled for most of system service processes.
  • Personalized Seccomp policies can be enabled for the native service processes incubated by the init process.

Enabling Seccomp

When to Use

To meet product security requirements, you can enable Seccomp to limit the scope of system calls that can be invoked by processes. The development procedure below describes how to enable the basic functions and policies of Seccomp. Note that the basic functions must meet the feature restrictions described in Constraints. For details about the basic policy file, see Policy File Overview.

How to Develop

1. Add the following field to vendor/Product vendor/Product name/config.json:

   "build_seccomp": true
   

   The following is an example of adding the build_seccomp field to the product configuration file:

   {
       "product_name": "MyProduct",
       "version": "3.0",
       "type": "standard",
       "target_cpu": "arm",
       "ohos_version": "OpenHarmony 1.0",
       "device_company": "MyProductVendor",
       "board": "MySOC",
       "enable_ramdisk": true,
       "build_seccomp": true
       "subsystems": [
       {
           "subsystem": "ace",
           "components": [
           { "component": "ace_engine_lite","features":[""] }
           ]
       },
       ...
       ]
   }
   

2. Perform a full build on the product code to generate an image.

   ./build.sh --product-name *product name* --ccache --build-target make_all --target-cpu *specified CPU*
   

3. Burn the image into the device.

Debugging and Verification

Check whether Seccomp is enabled for application processes and system service processes.

1. Run the shell command to obtain the process ID (that is, target pid) of the target process.

   ps -ef | grep xxx
   

   Information similar to the following is displayed, in which target pid is 1686:

   media         1686     1 0 08:16:12 ?     00:00:00 xxx
   root          1869  1678 4 10:32:29 pts/0 00:00:00 grep xxx
   

2. Check the process status to determine whether Seccomp is enabled.

   cat /proc/[target pid]/status | grep Seccomp
   

   Information similar to the following is displayed:

   Seccomp:        2
   Seccomp_filters:        1
   

   Table 1 Description of the Seccomp status

Customizing Seccomp Policies for a Process

When to Use

If the basic Seccomp policy has been enabled for a product, you can customize Seccomp policies for native service processes incubated by the init process to adapt to diversified security requirements. In this case, the Seccomp policies of other native service processes remain unchanged.

How to Develop

1. Collect statistics on the system calls required by the 32-bit and 64-bit systems by using the static analysis and Strace statistics methods described in System Call Statistic Methods. In this way, you will obtain the initial Seccomp policy.

2. Write a policy file. For details, see How to Write a Common Policy File.

3. Write and build the BUILD.gn file.

   1. Store the policy file in the code repository of the service subsystem and create a BUILD.gn file. For example, create the seccomp_policy folder in the service code repository, and create the policy file and BUILD.gn file in the folder.

      //path/to/code/seccomp_policy
      ├── BUILD.gn
      └── example.seccomp.policy
      

   2. To parse the policy file and build the policy dynamic library, use the ohos_prebuilt_seccomp template to declare the Seccomp policy file path of the process in the BUILD.gn file. The ohos_prebuilt_seccomp template is defined in the //base/startup/init/services/modules/seccomp/scripts/seccomp_policy_fixer.gni file. The following table describes the parameters in the template.

      Table 2 Parameters in the ohos_prebuilt_seccomp template

    Example
    ```python
    #Import the template file.
    import("//base/startup/init/services/modules/seccomp/scripts/seccomp_policy_fixer.gni")

    #Use the ohos_prebuilt_seccomp template.
    ohos_prebuilt_seccomp("xxxx_seccomp_filter") {
        sources = [ "xxxx.seccomp.policy" ]
        
        filtername = "xxx"

        process_type = "system"

        part_name = "xx_part_name"
        subsystem_name = "x_subsystem_name"

        install_enable = true
        install_images = [ "xxxxx" ]
    }
    ```
3. Add the build target of **xxxx_seccomp_filter** to other **BUILD.gn** files.
    ```python
    if (build_seccomp) {
        deps += [ "path:xxxx_seccomp_filter" ]
    }
    ```

4. Build the dynamic policy library libxxx_filter.z.so.

   ./build.sh --product-name *product name* --ccache --build-target xxxx_seccomp_filter --target-cpu *specified CPU*
   

   If an error message that contains the following information is reported, the process needs to use the system calls in the baseline blocklist. In such a case, you need to declare the corresponding system call in privileged_process.seccomp.policy. For details, see How to Write a Privileged Process Policy File. After the declaration is done, try again until the build is successful.

   xx of allow list is in block list
   

5. Use the hdc tool to push the dynamic policy library to the device and restart the device.

   # Push an appropriate library path based on the installation location in the image. For example, if the image is **system** and the system architecture is 32-bit, the path of the dynamic policy library is **/system/lib/seccomp/**.
   hdc shell mount -rw -o remount /
   hdc file send /path/to/libxxx_filter.z.so /path/to/lib(or lib64)/seccomp/
   hdc shell reboot
   

6. Use the audit statistics method to check and supplement the Seccomp policies. Repeat steps 4 to 6 until the process can run properly.

Debugging and Verification

1. If Seccomp is not enabled for the target process, check the Seccomp status of the target process.
2. If the process is terminated and audit log information is present in the kernel logs, the Seccomp policy is enabled but the policy list is incomplete. You can find an example audit log in Audit Statistics.
3. If the process is not terminated, comment out the system calls (for example, setuid) related to the specified uid in the Seccomp policy file. Rebuild the dynamic policy library, push the library to the image, and restart the process. Then, check whether the process is terminated by Seccomp. If the process is terminated, Seccomp has been enabled.

FAQs

How do I determine whether a process termination is caused by Seccomp?

Symptom

If a process is terminated under certain conditions, how do I determine whether the issue is caused by Seccomp?

Solution

Use either of the following methods:

• Check the crash stack backtrace log of the process. If the signal in the log is SIGSYS, the process termination is caused by the Seccomp mechanism. To view the crash stack backtrace content, run the following shell command:

  cat /data/log/faultlog/faultlogger/crash stack backtrace log
  

  Example output:

  Generated by HiviewDFX@OpenHarmony
  ================================================================
  Device info:xxx
  Build info:xxx
  Module name:xxx
  Pid:xxxx
  Uid:xxxxx
  Reason:Signal:SIGSYS(UNKNOWN)
  ...
  

• Check whether the process is still terminated after Seccomp is disabled. If the process runs properly after Seccomp is disabled, the process termination is caused by Seccomp.

  Seccomp is enabled by default. When the device operation mode is set to root, you can run the shell command to set the corresponding system parameter to disable Seccomp of the entire system.

  # Set the system parameter to disable Seccomp and restart the process.
  param set persist.init.debug.seccomp.enable 0; reboot
  # Set the system parameter to enable Seccomp and restart the process.
  param set persist.init.debug.seccomp.enable 1; reboot
  

Reference

Seccomp source code directory

base/startup/init/services/modules/seccomp
├── BUILD.gn
├── gen_syscall_name_nrs.c
├── scripts
│   ├── generate_code_from_policy.py        # Policy file parsing script
│   ├── seccomp_policy_fixer.gni            # Template definition in the BUILD.gn file for generating the dynamic policy library
│   └── tools                               # Scripts for collecting system call statistics
├── seccomp_policy                          # Basic policy files
│   ├── app.blocklist.seccomp.policy
│   ├── app.seccomp.policy
│   ├── privileged_process.seccomp.policy
│   ├── renderer.seccomp.policy
│   ├── spawn.seccomp.policy
│   ├── system.blocklist.seccomp.policy
│   └── system.seccomp.policy
├── seccomp_policy.c                        # Core Seccomp implementation code
└── seccomp_policy_static.c                 # Seccomp plug-in code

Policy File Overview

• Location
  Basic policy files are stored in //base/startup/init/services/modules/seccomp/seccomp_policy.

• Basic policy files

  Table 3 Description of policy files

How to Write a Common Policy File

• To declare a configuration item, write @ followed by the configuration item, for example, @returnValue.
• Add the content of a configuration item from the next line of this configuration item to the beginning of the next configuration item.
• To comment out a line, add a pound sign (#) at the beginning of this line.
• Set the system architecture to arm or arm64. Only these two system architectures are supported currently.
• Separate system calls from the system architecture by a semicolon (;). The value all indicates that the system calls will be used by all supported system architectures.
• Set other parameters as needed. Except returnValue, all the other parameters are optional.

Table 4 Configuration items in the policy file

Example: example.seccomp.policy

@returnValue
TRAP

@headFiles
"time.h"

@priority
ioctl;all

@allowList
openat;all
close;all
lseek;all
read;all
write;all
setresuid;arm64
setresgid;arm64
setresuid32;arm
setresgid32;arm

@allowListWithArgs
clock_getres:if arg0 >= CLOCK_REALTIME && arg0 <= CLOCK_BOOTTIME; return ALLOW; else return TRAP;all

@blockList
swapon;all

@selfDefineSyscall
787

How to Write a Privileged Process Policy File

• To declare a configuration item, write @ followed by the configuration item, for example, @allowBlockList.
• Add the content of a configuration item from the next line of this configuration item to the beginning of the next configuration item.
• To comment out a line, add a pound sign (#) at the beginning of this line.
• Set the system architecture to arm or arm64. Only these two system architectures are supported currently.
• Separate system calls from the system architecture by a semicolon (;). The value all indicates that the system calls will be used by all supported system architectures.

Table 5 Configuration items in the privileged process policy file

The following example shows how to enable process1 and process2 to use the swapon system call in the baseline blocklist.

@privilegedProcessName
process1

@allowBlockList
swapon;all

@privilegedProcessName
process2

@allowBlockList
swapon;all

System Call Statistic Methods

Table 6 Comparison of statistic methods

Static Analysis

1. Prepare the environment.

   1. Prepare a Linux environment.

   2. Download the cross compilers arm-linux-musleabi and aarch64-linux-musl.

      wget https://musl.cc/arm-linux-musleabi-cross.tgz
      wget https://musl.cc/aarch64-linux-musl-cross.tgz
      
      tar -zxvf arm-linux-musleabi-cross.tgz
      tar -zxvf aarch64-linux-musl-cross.tgz
      
      # Add the tool execution path to the environment variable.
      export PATH=$PATH:/path/to/arm-linux-musleabi-cross/bin
      export PATH=$PATH:/path/to/aarch64-linux-musl-cross/bin
      

   3. Download the OpenHarmony source code. For details, see Obtaining Source Code.

2. Compile seccomp_filter to obtain the dependency files libsyscall_to_nr_arm and libsyscall_to_nr_arm64.

   seccomp_filter is declared in base/startup/init/services/modules/seccomp/BUILD.gn and is used to build the basic dynamic policy library of Seccomp. After the compilation is complete, dependency files are generated in //out/Product name /gen/base/startup/init/services/modules/seccomp/gen_system_filter/.

   ./build.sh --product-name *product name* --ccache --build-target seccomp_filter --target-cpu *specified CPU*
   
   # Copy the dependency files to the tool folder for later use.
   cp out/*product name* /gen/base/startup/init/services/modules/seccomp/gen_system_filter/libsyscall_to_nr_arm* base/startup/init/services/modules/seccomp/scripts/tools/
   

3. Copy the generate_code_from_policy.py script file to the tool folder. This script file is available at //base/startup/init/services/modules/seccomp/scripts/.

   # Go to the root directory of the OpenHarmony source code.
   cd /root/to/OpenHarmonyCode;
   # Go to the directory where the **generate_code_from_policy.py** script file is located.
   cd base/startup/init/services/modules/seccomp/scripts/;
   # Copy the **generate_code_from_policy.py** script file.
   cp generate_code_from_policy.py tools/;
   

4. Compile ELF files related to the service code. In the 32-bit architecture, the implementation of disassembly code redirection for ELF files is complex. Therefore, ELF files are all compiled into 64-bit ELF files to parse the function call relationship.

   ./build.sh --product-name *product file* --ccache --target-cpu arm64 --build-target *target file*
   

5. If full build has not been performed before and the dependent dynamic libraries for step 4 are not in the //out directory, copy the related dynamic libraries to the //out directory. The following code is for reference only. If other dynamic libraries are involved, copy them in a similar way.

   # Go to the root directory of the source code.
   cd /root/to/OpenHarmonyCode
   # Create the **aarch64-linux-ohos** folder in **out/*product name*/lib.unstripped/** to store the dependent dynamic libraries.
   mkdir out/*product name*/lib.unstripped/aarch64-linux-ohos
   # Copy the related dynamic libraries to the //out directory.
   cp prebuilts/clang/ohos/${host_platform_dir}/llvm/lib/clang/${clang_version}/lib/aarch64-linux-ohos/*.so out/*product name*/lib.unstripped/aarch64-linux-ohos/
   cp prebuilts/clang/ohos/${host_platform_dir}/${clang_version}/llvm/lib/aarch64-linux-ohos/*.so out/*product name*/lib.unstripped/aarch64-linux-ohos/
   

6. Modify the collect_elf_syscall.py script file, and change the paths of the objdump and readelf tools to their absolute paths in the Linux environment. This script file is available at base/startup/init/services/modules/seccomp/scripts/tools/. The objdump and readelf tools available at //prebuilts.

   #modified the path of objdump and readelf path
   def get_obj_dump_path():
       obj_dump_path = '/path/to/llvm-objdump'
       return obj_dump_path
   
   
   def get_read_elf_path():
       read_elf_path = '/path/to/llvm-readelf'
       return read_elf_path
   

7. Use the collect_elf_syscall.py script file to parse and generate the corresponding policy file xxx.seccomp.policy.

   Table 7 Parameters in the collect_elf_syscall.py script file

Use **collect_elf_syscall.py** to parse ELF files.

    ```
    # The following example considers **rk3568** as the product and **libmedia_service.z.so** as the ELF file.
    python3 collect_elf_syscall.py --src-elf-path ~/ohcode/out/rk3568 --elf-name libmedia_service.z.so --src-syscall-path libsyscall_to_nr_arm64 --target-cpu arm64 --filter-name media_service
    ```

    Example result of xxx.seccomp.policy 
    ```
    @allowList
    getcwd;arm64
    eventfd2;arm64
    epoll_create1;arm64
    epoll_ctl;arm64
    dup;arm64
    dup3;arm64
    fcntl;arm64
    ioctl;arm64
    ...
    ```

Strace Statistics

1. Use the cross compilers arm-linux-musleabi and aarch64-linux-musl to build the Strace tool for the 32-bit and 64-bit architectures, respectively.
2. Trace the service process to obtain the Strace logs.
3. Parse Strace logs by using scripts to obtain the Seccomp policy file.

Tracing the Service Process

1. Modify the embedded code in the init repository. Specifically, add the following content to //base/startup/init/services/init/init_common_service.c before executing the SetSystemseccompPolicy function to set the Seccomp policy. If the line starts with a plus sign (+), the line is added; if the line starts with a hyphen (-), the line is deleted. xxxx must be the same as the value of Services name in the boot configuration file of the process.

   --- a/services/init/init_common_service.c
   +++ b/services/init/init_common_service.c
   @@ -155,7 +155,19 @@ static int SetPerms(const Service *service)
       // set seccomp policy before setuid
       INIT_ERROR_CHECK(SetSystemseccompPolicy(service) == SERVICE_SUCCESS, return SERVICE_FAILURE,
           "set seccomp policy failed for service %s", service->name);
   -
   +    if (strncmp(service->name, "xxxx", strlen("xxxx")) == 0) {
   +        pid_t pid = getpid();
   +        pid_t pid_child = fork();
   +        if (pid_child == 0) {
   +            char pidStr[9] = {0};
   +            sprintf_s(pidStr, 6, "%d", pid);
   +            if (execl("/system/bin/strace", "/system/bin/strace", "-p", (const char *)pidStr, "-ff", "-o", "/data/strace/xxxx.strace.log", NULL) !=0 ) {
   +                INIT_LOGE("strace failed");
   +            }
   +        }
   +        sleep(5);
   +    }
       if (service->servPerm.uID != 0) {
           if (setuid(service->servPerm.uID) != 0) {
               INIT_LOGE("setuid of service: %s failed, uid = %d", service->name, service->servPerm.uID);
   

2. Perform a full build, and burn the image.
3. Disable SElinux, and push Strace to the device.

   hdc shell setenforce 0
   hdc shell mount -rw -o remount /
   hdc file send /path/to/strace /system/bin/
   hdc shell chmod a+x /system/bin/strace
   

4. Create a folder for storing Strace logs.

   hdc shell mkdir -p /data/strace
   

5. Terminate the service process, and restart it. In the following command, xxx indicates the service process name.

   kill -9 $(pidof xxx)
   

6. Perform service operations on the device. Make sure that all code is covered.
7. Obtain Strace logs from /data/strace on the device, and save them to the directory where the parsing script is located.

   hdc file recv /data/strace /path/to/base/startup/init/services/modules/seccomp/scripts/tools/
   

Parsing Strace Logs

1. Copy the dependency files to the Strace log folder for later use. The dependency files are those generated in step 2 in Static Analysis.

   cp out/*product name* /gen/base/startup/init/services/modules/seccomp/gen_system_filter/libsyscall_to_nr_arm* base/startup/init/services/modules/seccomp/scripts/tools/strace/
   

2. Use the strace_log_analysis.py script file to parse and generate the corresponding policy file xxx.seccomp.policy.

   The script file is available at //base/startup/init/services/modules/seccomp/scripts/tools/.

   Table 8 Parameters in the strace_log_analysis.py script file

Use the **strace_log_analysis.py** script file to parse Strace logs.
```shell
cd base/startup/init/services/modules/seccomp/scripts/tools;
python3 strace_log_analysis.py --src-path strace --target-cpu *specified CPU* --filter-name xxx
```
Example result of xxx.seccomp.policy 
```
@allowList
getcwd;arm64
eventfd2;arm64
epoll_create1;arm64
epoll_ctl;arm64
dup;arm64
dup3;arm64
fcntl;arm64
ioctl;arm64
...
```

Audit Statistics

1. Enable the initial Seccomp policy. For details, see Customizing Seccomp Policies for a Process.

2. Obtain logs.

   1. Create a folder for storing logs.

      mkdir -p /data/audit
      

   2. Obtain Seccomp-related audit log information from kernel logs. The logs end with .audit.log.

      cat /proc/kmsg | grep type=1326 > /data/audit/media_service.audit.log
      

3. Perform service-related operations and segment fault triggering operations.

   1. To trigger a segment fault, add the following code to the service code to call TriggerSegmentFault at a certain point to rebuild and burn the image:

      static void TriggerSegmentFault(void)
      {
          pid_t pid_child = fork();
          if (pid_child == 0) {
              char *test = (char *)0x1234;
              *test = 1;
          }
      }
      

   2. After the device is started, run the following shell command to temporarily shut down SELinux and terminate the service process. The process then automatically restarts.

      setenforce 0
      

4. Run the hdc command to obtain audit logs from the /data/audit on of the device, and save them to the directory where the parsing script is located.

   hdc file recv /data/audit /path/to/base/startup/init/services/modules/seccomp/scripts/tools/
   

5. Parse the audit logs.

   Example audit log:

   <5>[  198.963101] audit: type=1326 audit(1659528178.748:27): auid=4294967295 uid=0 gid=1000 ses=4294967295 subj=u:r:appspawn:s0 pid=2704 comm="config_dialog_s" exe="/system/bin/appspawn" sig=31 arch=40000028 syscall=208 compat=1 ip=0xf7b79400 code=0x80000000
   

   Table 9 Key parameters in audit logs

1. Copy the dependency files to the log folder for later use. The dependency files are those generated in step 2 in [Static Analysis](#static-analysis).
    ```shell
    cp out/*product name* /gen/base/startup/init/services/modules/seccomp/gen_system_filter/libsyscall_to_nr_arm* base/startup/init/services/modules/seccomp/scripts/tools/audit/
    ```
2. Run the **audit_log_analysis.py** script to parse logs and generate **xxx.seccomp.policy**. The tool is available at **//base/startup/init/services/modules/seccomp/scripts/tools/**.

    **Table 10** Parameters in the audit_log_analysis.py script file

    ```shell
    cd base/startup/init/services/modules/seccomp/scripts/tools
    python3 audit_log_analysis.py --src-path audit --filter-name xxx
    ```

Combining Multiple Policy Files

During colltatistics on system calls, multiple policy files may be generated. In these policy files, system calls may be repeated or disordered. To solve these problems, you can combine policy files to sort system calls by arm64/arm and by system call number in ascending order.

Table 11 Parameters in the merge_policy.py script file

1. Copy the dependency files to the log folder for later use.

   cp out/*product name* /gen/base/startup/init/services/modules/seccomp/gen_system_filter/libsyscall_to_nr_arm* base/startup/init/services/modules/seccomp/scripts/tools/
   

2. Run the merge_policy.py script to merge policy1.seccomp.policy and policy2.seccomp.policy into xxxx.seccomp.policy.

   python3 merge_policy.py --src-files libsyscall_to_nr_arm --src-files libsyscall_to_nr_arm64 --src-files policy1.seccomp.policy --src-files policy2.seccomp.policy --filter-name xxxx