Chapter 13: Judging execute requests outside of the kernel
13.1. task denied_execute_handler
A system administrator using AKARI will generally know the programs that need to be executed from any particular domain. Thus, a normally functioning system will generally not make any execution requests that violate policy. If such an execution request occurs, such as /bin/bash, from a domain that does not usually need to make that execution, then the domain has probably been compromised.
At this point, the kernel will reject the request. However, it is unlikely that the domain will regain control from the attacker. This is where the task denied_execute_handler directive can be useful. This directive allows an external program to be called whenever an execute request is rejected. This external program can for example be /bin/true, which will cause the process that made the execute request to terminate immediately. The process is therefore no longer compromised.
Any other programs can be specified using this directive. It can be useful to run a honeypot program to observe the actions of the attacker, to show a warning message, or to change the configuration of a firewall to derive the IP address of the attacker.
This directive should be placed in domain policy for the appropriate domain, and will only function if the domain is in "Enforcing Mode":
task denied_execute_handler /bin/true
The directive takes the following parameters:
Parameter |
Contents |
|---|---|
argv[0] |
The pathname of the program specified by the directive |
argv[1] |
The name of the domain that made the execute request |
argv[2] |
The name of the program that made the execute request |
argv[3] |
The information (e.g. UID) of the process that made the execute request |
argv[4] |
The name of the program that the domain tried to execute |
argv[5] |
The number of command line arguments (argc) passed to the execution request |
argv[6] |
The number of environment variables (envc) passed to the execution request |
argv[7] to argv[6 + argc] |
The command line arguments passed to the execution request |
argv[7 + argc] to argv[6 + argc + envc] |
The environment variables passed to the execution request |
Important notes:
- The program specified by the directive should not be specified by the file execute directive.
- The domain for the program specified by the directive should be placed in "Enforcing Mode".
- All environment variables are cleared before executing the program specified by the directive. This is to prevent dangerous environment variables like LD_PRELOAD from affecting the program. Note that even PATH is cleared. Other resources such as standard input and output are inherited.
- If the process making the request is in a chroot environment, the directive will only function if the program specified by the directive is within the chroot.
13.2. task auto_execute_handler
Normally, when a domain makes an execution request, the kernal checks policy to determine whether it should be allowed or rejected. However, judging this within the kernel has some limitations. There are few library functions available and it is more likely to fail when allocating a contiguous area of memory. This is where the task auto_execute_handler directive can be useful in judging the execution request outside of the kernel, which allows the use of many library functions and more consistent allocation of a contiguous area of memory. However, there is one downside to this approach. There are no means of notifying the process that made the execution request that the execution failed.
This is useful in creating any external program you wish, and you can even judge by using SSH to ask remotely. You can use audit-exec-param which comes with the userspace tools package as a templete for utilizing this directive.
audit-exec-param | This program acts as a preprocessor for auditing command line arguments and environment variables passed to execute requests. |
This directive should be placed in domain policy for the appropriate domain:
task auto_execute_handler /usr/lib/ccs/audit-exec-param
The directive takes the same arguments described in 13.1. task denied_execute_handler.
Important notes:
- All environment variables are cleared before executing the program specified by the directive. This is to prevent dangerous environment variables like LD_PRELOAD from affecting the program. Note that even PATH is cleared. Other resources such as standard input and output are inherited.
- If the process making the request is in a chroot environment, the directive will only function if the program specified by the directive is within the chroot.