Troubleshooting “secons -sk” error message '.. there is another system call intercepting ..'
Article ID: 415175
Updated On:
Products
Issue/Introduction
When running the “secons -sk” command to shut down PAMSC services, it fails with the error message, "Shutting down seosd is not allowed because there is another system call intercepting product started after CA Privileged Access Manager Server Control.". This means that PAMSC is being shut down out of order. (Commonly known system call intercepting products are anti-virus, anti-spamware or access control products.)
The error message is introduced in a new feature since 14.1 CP5. This new feature does a pre-shutdown check. If it detects that another product has enabled system call interception after PAMSC, it will show the error message
Environment
PAMSC 14.1 CP5. and up
Cause
When a system call is intercepted by multiple products, the hooking function of each product will be executed in the reverse order of activation. That is, the last activated product’s hooking function will be executed first. Upon completion, it will execute the hooking function of another product that has been activated before it, and eventually the original system call function after all hooking functions are executed. This is how multiple system call intercepting products coexist. This means that the interception mechanism works like a stack, last-in-first-out. When shutting down one product, you will have to shut down those activated after yours in the reverse order.
Since each product is working independently without any knowledge of other products, PAMSC introduced a pre-shutdown check to prevent PAMSC from disabling system call interception out of order. When shutting down PAMSC, specifically seosd, it needs to disable system call interception before termination. Before disabling interception, it checks if any of the intercepted system calls are also being intercepted by another product. If one is detected, an attempt to shut down seosd will be aborted with the error message seen. PAMSC status will remain the same and continue to work.
Please note that this error is different from the error often seen when attempting to unload the SEOS kernel module. This error occurs when attempting to disable system call interception when terminating seosd. The unload error happens when there are processes still being intercepted by PAMSC, for instance, a process calling the accept system call to wait for incoming network connection. The "secons -scl" command, in the latter scenario, identifies processes that are still intercepted by PAMSC. Terminating or restarting these processes will resolve the SEOS kernel module unload issue; however, it will not resolve the “secons -sk” problem.
Resolution
To resolve this, users need to find out which third-party product, specifically the kernel module, has been enabled after PAMSC and then shut it down before shutting down PAMSC.
Run the following commands as root to identify the kernel modules involved.
# cd /proc/`cat /proc/seos_enabled`
# echo 32 > virtual_syscall
# cat virtual_syscall
# echo 0 > virtual_syscall
Here is a sample output of “cat virtual_syscall”.
PAMSC virtual syscall.
SEOS_flags=0x7
SEOSF_INITIALIZED - Module initialized
SEOSF_INTERCEPT - Interception enabled
SEOSF_INTERCEPT_KILL - Terminating daemons disallowed
!SEOSF_UNLOAD_READY - Module NOT ready to unload
SEOS_debug_flags (mask)=0x00000020
SEOSDF_NONE - 0x00000000 (0)
SEOSDF_DEBUG - 0x00000001 (1) Off - Debugging mode
Available Debugging Categories:
SEOSDF_GENERIC - 0X00000010 (16) Off - Generic
SEOSDF_INTERCEPT_TABLE - 0x00000020 (32) On - Syscall interception table
SEOSDF_MEMORY_CHECK - 0x00000040 (64) Off - Memory check
Syscall Name Hooked Original Address Hook Function Current Address
--------------- ------ ------------------ ------------------ ------------------
__x64_sys_setuid Y ffffffff81f127c0 ffffffffc09cde40 ffffffffc09cde40
__x64_sys_setgid Y ffffffff81f12480 ffffffffc09ce850 ffffffffc09ce850
__x64_sys_setgroups Y ffffffff81f254b0 ffffffffc09d01c0 ffffffffc09d01c0
__x64_sys_fork Y ffffffff81ef8840 ffffffffc09d58c0 ffffffffc09d58c0
__x64_sys_accept Y ffffffff82626360 ffffffffc09d0870 ffffffffc09d0870
__x64_sys_clone Y ffffffff81ef8880 ffffffffc09d5db0 ffffffffc09d5db0
__x64_sys_execve Y ffffffff82176990 ffffffffc09db580 ffffffffc09db580
__x64_sys_open Y ffffffffc0795950 ffffffffc09dc4b0 ffffffffc07b6960 *
__x64_sys_creat Y ffffffffc0795a80 ffffffffc09dc680 ffffffffc07b6a90 *
__x64_sys_link Y ffffffffc0794c20 ffffffffc09dcad0 ffffffffc07b5c30 *
__x64_sys_symlink Y ffffffffc0792b70 ffffffffc09dcf10 ffffffffc07b3b80 *
__x64_sys_unlink Y ffffffffc0795700 ffffffffc09dd270 ffffffffc07b6710 *
__x64_sys_mknod Y ffffffff821813c0 ffffffffc09dd620 ffffffffc09dd620
__x64_sys_chmod Y ffffffffc07949a0 ffffffffc09dd970 ffffffffc07b59b0 *
__x64_sys_chown Y ffffffffc0794620 ffffffffc09ddbc0 ffffffffc07b5630 *
__x64_sys_reboot Y ffffffff81f22890 ffffffffc09cda40 ffffffffc09cda40
. . .
(*) indicates there is another system call intercepting products started after PAMSC.
This table contains 5 columns/fields.
Syscall Name is the name of the system call.
Hooked shows if it is hooked or not.
Original Address is the function address of the system call before PAMSC is activated. If PAMSC is the only product running, this is the original system call function pointer.
Hook Function is the function address of PAMSC’s hooking function.
Current Address is the function address in the system call table. If PAMSC is the last activated product or the only product, this will be the same as the Hook Function address.
If the current address is different from the hook function, it means another product has activated after PAMSC and there will be a “*” marked next to the function. To identify the kernel modules that have been activated after PAMSC, you need to use the current address to look up the function name and its module name.
First you can search it in /proc/kallsyms by running the following command:
# grep <your_current_address> /proc/kallsyms
<your_current_address> is the current address of interest, for example ffffffffc07b6960.
If it is not found, it could be that symbols of the module are not updated in the system symbol table or are protected. In this situation, you will need to search all loaded kernel modules and their kernel memory addresses to determine which module memory address the current address falls into.
To list loaded kernel modules and their memory address, use the following commands:
# cat /proc/modules | awk '{printf("%s\t%s\n", $6, $1)}' | sort -k 1
0xffffffffc01c6000 fuse
0xffffffffc01ed000 dm_mod
0xffffffffc0214000 dm_log
0xffffffffc021a000 dm_region_hash
0xffffffffc0220000 dm_mirror
0xffffffffc0228000 binfmt_misc
. . .
0xffffffffc072d000 udp_diag
0xffffffffc0732000 falcon_kal
0xffffffffc0743000 falcon_nf_netcontain
0xffffffffc0788000 falcon_lsm_pinned_18108
0xffffffffc07a9000 falcon_lsm_pinned_18202
0xffffffffc09c3000 seos_1410_70_70
0xffffffffc0e70000 nf_tables
0xffffffffc0ea0000 falcon_lsm_serviceable
This shows the current address of ffffffffc07b6960 is within the falcon_lsm_pinned_18202 module. Users will need to shut down this kernel module and its related service first before attempting to shut down PAMSC.
Feedback
