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: c "build_seccomp": true The following is an example of adding the build_seccomp field to the product configuration file: c { "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

1. Check the process status to determine whether Seccomp is enabled. shell 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 | Parameter| Description| | —| —| | Seccomp| - 0: disabled.
   - 1: enabled with the strict mode. Only the read, write, exit, and sigreturn system calls are allowed.
   - 2: enabled with the filter mode. The customized policies can be enabled by loading BPF instruction sets.| | Seccomp_filters| Number of Seccomp policies set for a process.|

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 | Parameter| Description| | —| —| | sources| Path of the policy configuration file, mandatory.| | filtername| Filter name, mandatory. The value must be the same as the value of Services name in the boot configuration file of the process. Otherwise, the attempt to enable Seccomp will fail. This parameter determines the name of the dynamic policy library generated after the build. For example, if filtername is set to xxx, the name of the dynamic policy library is libxxx_filter.z.so.| | process_type| Process type, mandatory. If the process is one incubated by the init process, set this parameter to system; if the process is an application process, set this parameter to app.| | part_name| Part name, mandatory.| | subsystem_name| Subsystem name, mandatory.| | install_enable| Option specifying whether to install the policy file to the image, mandatory. Set the value to true.| | install_images| Installation location in the image, mandatory.|

      Example

      #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.

      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: shell cat /data/log/faultlog/faultlogger/crash stack backtrace log Example output: shell 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 | Policy File| Description| | —| —| | system.seccomp.policy|Seccomp policy enabled for most of system service processes.| | system.blocklist.seccomp.policy|System call baseline blocklist for system processes, that is, the list of system calls that cannot be invoked by non-privileged processes.| | app.seccomp.policy|Seccomp policy enabled for all application processes.| | app.blocklist.seccomp.policy|System call baseline blocklist for application processes, that is, the list of system calls that cannot be invoked by application processes.| | spawn.seccomp.policy|Seccomp policy enabled for the appspawn and nwebspawn processes.| | renderer.seccomp.policy|Seccomp policy enabled for the rendering processes incubated by the nwebspawn process.| | privileged_process.seccomp.policy|Privileged process policy file. If certain processes need to use the system calls on the baseline blocklist, you need to declare the corresponding process identifiers and baseline blocklists in this file.|

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

| Item| Description|Configuration Rule| | —| —| –| | returnValue| Return value.| This parameter is mandatory. Value range:
- LOG: tolerant mode, in which only audit logs are recorded and the process is not terminated.
- TRAP: a mode in which the process is terminated and can be passed on to the faultloggerd process.
- KILL_PROCESS: a mode in which the process is terminated.
- KILL_THREAD: a mode in which the thread is terminated.| | headFiles| Header file, which is used to declare the macros in the allowListWithArgs and priorityWithArgs parameters.| Use ”” and <> to include the file name, for example, and “cde.h”. The default header files are , , , and .| | priority| Allowlist of frequently used system calls.| System calls on the list are treated with a higher priority to improve the performance.| | priorityWithArgs| Allowlist of frequently used system calls with arguments.| System calls on the list are treated with a higher priority to improve the performance.| | allowList| Allowlist| List of system calls that can be invoked by a process.| | allowListWithArgs| List of system calls with arguments that can be invoked by a process.| Separate the system call name and argument by a colon (:). Supported relational operators include <, <=, >, >=, ==, !=, and &, and supported logical operators include && and .||.
Use argn to specify the SN of the argument in the system. The value of n ranges from 0 to 5. A judgment statement starts with if and ends with else. Declare the return value after the statement ends, and use a semicolon (;) to separate the judgment statement from the return value.
The return value must be in the format of return xxx, where the value range of xxx is the same as that of returnValue. If there are multiple conditions in the judgment statement, separate them with elif.| | blockList| Blocklist of system calls.| Before generating BPF instructions during policy file parsing, the system checks whether the system calls on the allowlist exist in the blocklist. If yes, a parsing error occurs.| | selfDefineSyscall| Customized system call.| Set the value of this parameter to a number.|

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 | Item| Description|Configuration Rule| | —| —| –| | privilegedProcessName| Process name identifier.| Character string corresponding to name in the services parameter in the boot file of the native service process.| | allowBlockList| Available baseline blocklist.| Fill in the system call and the system architecture.|

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 | Statistic Method| Description| Advantage| Disadvantage| | —| —| —| —| |