Using Seccomp to filter Syscalls for Fenced Mode Process (FMP)
You can use the Seccomp Functionality to control and filter Syscalls made for stored procedures and user defined functions running in a Db2® Fenced Mode Process (FMP).
Secure computing mode (Seccomp) is a Linux Kernel feature that allows you to monitor and control the Syscalls that a process can make to the Linux Kernel. Using the libseccomp library, you can define rules for a Syscall that allows you to monitor and perform actions on the Syscalls made on your system.
Usage
You can enable The Seccomp Syscall filtering functionality via the DB2_SECCOMP_ENABLE registry variable by using the db2set command.
When the Seccomp Syscall filtering functionality is enabled, the
DB2_SECCOMP_ENABLE registry variable is applied to all Syscalls. All the
actions (seccompAction) are restrictive, and Syscalls are allowed by specifying them in a
configuration file through the configurationFilePath parameter of
DB2_SECCOMP_ENABLE. A hidden internal list of allowed Syscalls is also
automatically added which is the minimum needed for Db2 Fenced Mode Process (FMP) to run required by
operations such as error handling, FODC generation, and so on.
The Registry variable change is not dynamic. Changes to the DB2_SECCOMP_ENABLE registry variable and the configuration file do not apply to active Fenced Mode Process (FMP).
To refresh settings You can use the db2stop or db2start commands to automatically terminate all existing Fenced Mode Processes (FMP) in the Fenced pool. For more information, see fenced_pool - Maximum number of fenced processes configuration parameter. You can also use the ADMIN_FMP_TERM command to manually terminate active Fenced Mode Processes (FMP). For more information, see ADMIN_FMP_TERM procedure. New stored procedure or UDF calls uses the new settings.
Syntax:
db2set DB2_SECCOMP_ENABLE=<seccompAction>db2set DB2_SECCOMP_ENABLE=<seccompAction>:<configurationFilePath>
db2set DB2_SECCOMP_ENABLE=<configurationFilePath>To enable the Seccomp Syscall filtering functionality, you can use the db2set command and pass a <seccompAction>. If the DB2_SECCOMP_ENABLE registry variable is not set, the <seccompAction> is turned "OFF". If the DB2_SECCOMP_ENABLE registry is set with <configurationFilePath> without a <seccompAction>, it defaults to "ON".
Parameter
- seccompAction:
- This is an optional input that specifies what to do with a syscall that is not "allowed".
"Allowed" Syscalls can be added in a configuration file pointed to by the parameter
<configurationFilePath>. Db2 also loads a hidden internal list of "allowed" Syscalls.
- ON
- When a syscall that is not "allowed" is invoked. Returns the errno EPERM.
- AUDIT
- When a syscall that is not "allowed" is invoked. Prints Syscall to the Linux Audit Logs.
- TRAP
- When a syscall that is not "allowed" is invoked. Sends a catchable SIGSYS signal.
- OFF
- Turn off DB2_SECCOMP_ENABLE registry variable.
- configurationFilePath:
This is an optional input that points to a configuration file path. This is a regular file that is manually created. The configuration file specifies a list of "allowed" Syscalls that is ignored by the seccompAction parameter. Db2 additionally loads in its own allowed list which is the minimum needed for Db2 Fenced Mode Process (FMP) to run.
Configuration File Syntax:Example configuration file:- Each line should contain only one syscall.
- Syscall must be valid for the given architecture, else it can stop FMP from starting.
- Comments can be made with a hash symbol "#". A comment can start on a brand new line or after a syscall.
- Leading and trailing whitespaces, blank lines are allowed.
Note: Some multiplexed Syscalls can require a direct Syscall number to be provided.#Seccomp config file # Used by DB2_SECCOMP_ENABLE to filter out syscalls. socket # Used by workload A getsockopt # Needed by workload B sysinfo # Need sysinfo to check msync getdents # We can have lines that are only comments, they will be ignored. capget mount 80 # Allow chdir, 80 refers to chdir on x86_64In this example, allowed Syscalls are socket, getsockopt, sysinfo, mysync, getdents, capget, mount, chdir is passed in as a direct syscall number, be sure to double check the syscall table for the given architecture.
Important: Do not use the configuration file provided in the example above. You must create your own configuration file with the configuration parameters that you need and provide it to the DB2_SECCOMP_ENABLE registry variable.The configuration should exist on the path that you provide with the appropriate <seccompAction>. You can also configure the DB2_SECCOMP_ENABLE registry variable without a <seccompAction>. In this case, the default option is ON. If the <configurationFilePath> and the <seccompActions> are not provided correctly, SQL0901N error message is displayed.
Scope and requirements
The Seccomp Syscall filtering functionality is only available on linuxamd64, linuxppcle, and
linux390. You must have the libseccomp library installed on your machine through a
package manager such as apt-get or yum. This functionality is applied only to user written user
defined functions (UDF) and stored procedures which run in Fenced Mode Processes (FMP). The Fenced
Mode Process is the db2fmp process which runs outside of db2sysc. It does not apply to the non
fenced mode process that are trusted to run within db2sysc. For more information
regarding Fenced Mode Process and non Fenced Mode Process, see What is the difference between running a fenced and unfenced external
routine? support page.
Limitations
- Unable to filter Syscalls for a specific user. When Syscalls are filtered using the Seccomp Syscall filtering functionality, they are filtered for all the users.
- Specific option for a specific Syscall is unavailable other than the default <seccompActions> mentioned above.
Example for the ON <seccompAction>
configurationFilePath value. (Later examples will show how to use
configurationFilePath). $db2set DB2_SECCOMP_ENABLE=ON
$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL1063N DB2START processing was successful.
$ db2 "call p1()"
Return Status = 0Example for the AUDIT <seccompAction>
The AUDIT option allows you to profile your own stored procedures and user defined function (UDF) to see what Syscalls are needed. Using the AUDIT option, when a Syscall that is not "allowed" is encountered. Db2 writes this to the Linux Audit logs. This information is helpful in curating a configuration file that can cater to the requirements of your stored procedures or UDFs. This is not recommended as the default option for a production environment as it does not offer additional protection against unwanted Syscall and does not block them. Here in this example, we set DB2_SECCOMP_ENABLE, refresh the settings and call procedure p1().
$db2set DB2_SECCOMP_ENABLE=AUDIT
$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL1063N DB2START processing was successful.
$ db2 "call p1()"
Return Status = 0All the Syscalls that are not allowed in the stored procedure provided above are recorded under /var/log/audit/. In this example, the procedure p1 made a "disallowed" syscall "symlink".
type=SECCOMP msg=audit(1718441758.789:296): auid=xxxxx uid=xxxxx gid=xxxxx ses=3 subj=kernel pid=6765 comm="Thread-0" exe="/home/user/sqllib/adm/db2fmp" sig=0 arch=c0000015 syscall=83 compat=0 ip=0x7fff8387a5f4 code=0x7ffc0000^]AUID="lamfung" UID="nobody" GID="nobody" ARCH=ppc64le SYSCALL=symlink
type=SECCOMP msg=audit(1718441758.789:296): auid=xxxxx uid=xxxxx gid=xxxxx ses=3 subj=kernel pid=6765 comm="Thread-0" exe="/home/user/sqllib/adm/db2fmp" sig=0 arch=c0000015 syscall=283 compat=0 ip=0x7fff8387a5f4 code=0x7ffc0000^]AUID="lamfung" UID="nobody" GID="nobody" ARCH=ppc64le SYSCALL=splice
Example of <seccompAction> AUDIT with <configurationFilePath>
In the previous example for the AUDIT parameter option, the syscall "symlink" and "splice" which are not on the "allowed" list are blocked and recorded in the audit log. If you need any Syscalls to be allowed, you can add it to the "allowed" list via the parameter <configurationFilePath>. Here is an example:
$ echo 'symlink' > /home/allowedList.cfg
$ echo 'splice' > /home/allowedList.cfg
$ db2set DB2_SECCOMP_ENABLE=AUDIT:/home/allowedList.cfg
$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL1063N DB2START processing was successful.
$ db2 "call p1()"
Return Status = 0Here the Syscalls "symlink" and "splice" are allowed and not recorded in the audit log.
Example for the TRAP <seccompAction>
When a Syscall is encountered that is not allowed, the TRAP option sends a catchable SIGSYS signal. This terminates the FMP, marks it unstable, and creates a FODC_fmpTrap directory with a stack of FMP process when the Syscall is encountered. You can profile the stored procedure or UDF with the AUDIT option to know what Syscalls are blocked. Alternatively, you can check the FODC_fmpTrap directory to see which Syscall encountered was not allowed. FODC_fmpTrap only records the first Syscall that is not allowed.
In this first example, we set DB2_SECCOMP_ENABLE with the TRAP seccompAction. We encountered a syscall that is not "allowed".
$ db2set DB2_SECCOMP_ENABLE=TRAP
$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL1063N DB2START processing was successful.
$ db2 "values cudf()"
1
-----------
SQL0430N User defined function "<user_name>.<Stored procedure name>" (specific name
"SQL240618003747930") has abnormally terminated. SQLSTATE=38503
In the following example, assuming the blocked Syscall encountered is "symlink", we can add the syscall "symlink" to the allowed list using configurationFilePath that allows the UDF to run.
$ echo 'symlink' > /home/lamfung/allowedList.cfg
$ db2set DB2_SECCOMP_ENABLE=TRAP:/home/lamfung/allowedList.cfg
$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL1063N DB2START processing was successful.
$ db2 "values cudf()"
1
-----------
0
1 record(s) selected.