--- title: "How to manage parent-child processes" slug: "how-to-manage-parent-child-processes" updated: 2026-11-03T14:48:17Z published: 2026-11-03T14:48:17Z canonical: "docs.senhasegura.io/how-to-manage-parent-child-processes" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # How to manage parent-child processes **Segura™ EPM** for Linux allows management and control of parent and child processes. Through access policies, administrators can define specific child processes that can be spawned or which parent processes are permitted to spawn certain child processes when configuring new policies. ## Use case: only the `bash` shell can execute the `ls` command We will create a rule that only allows the bash shell to execute the `ls` command. This configuration requires registering a new rule within the Segura™ Platform. 1. On Segura™ Platform, in the navigation bar, hover over the **Products menu** and select **EPM**. 2. In the side menu, select **Policies > Linux > Policies**. 3. Click **Add** to be directed to the policy selection screen. 4. Click the **Device** button. 5. On the **Access policy registration** form, navigate to the **General** tab and complete the following fields: 1. **Policy name:** fill in with `Only bash can execute “ls”`. 2. **Status**: select **Enable**. 3. **Guideline**: select **Execute** from the dropdown menu. 4. **Checker (path or executor):** fill in with `exec="/bin/ls"`. 5. **Enable audit**: select **Yes**. 6. On the **Rules** table, click the **Add** button and fill in: 1. **Allow or Lock**: select **Allow** from the dropdown menu. 2. **Rule Text**: fill in with the `task.exe="/bin/bash"`. 6. Navigate to the **Review** tab and click **Save**. ## Use case: the `bash` shell can execute only the `ls` command To enforce that the bash shell is restricted to executing only the `ls` command, a new rule must be created and registered within Segura™ Platform, as illustrated in the upcoming scenario. 1. On Segura™ Platform, in the navigation bar, hover over the **Products menu** and select **EPM**. 2. In the side menu, select **Policies > Linux > Policies**. 3. Click **Add** to be directed to the policy selection screen. 4. Click the **Device** button. 5. On the **Access policy registration** form, navigate to the **General** tab and complete the following fields: 1. **Policy name:** fill in with `Bash can only execute “ls”`. 2. **Status**: select **Enable**. 3. **Guideline**: select **Execute** from the dropdown menu. 4. **Checker (path or executor):** fill in with `exec="/bin/ls"`. 5. **Enable audit**: select **Yes**. 6. On the **Rules** table, click the **Add** button twice and fill in: 1. **Allow or Lock**: select **Allow** from the dropdown menu. 2. **Rule Text**: fill in with the `task.exe="/bin/bash"`. 3. **Allow or Lock**: select **Lock** from the dropdown menu. 4. **Rule Text**: fill in with the `*` to deny all the commands except the `ls`. 6. Navigate to the **Review** tab and click **Save**. Info We will apply the control of parent and child processes to any type of execution, including shell, software, and script. ## Validating the policy on the target device Here's an example illustrating the concept of parent-child processes. - We established the rule on the target device. - The database administrator user is permitted to write to the file. - The superuser will not have the capability to write to the file. View the `/sys/kernel/security/caitsith/policy` file to check the default **CaitSith** rules applied to the device. ``` root@debian:/root# cat /sys/kernel/security/caitsith/policy POLICY_VERSION = 20120401 stat Policy updated: 9036 (Last: 2019/12/24 00:31:57) stat Requests denied: 10 (Last: 2019/12/23 18:55:22) stat Memory used by policy: 4512 stat Memory used by audit: 63808 stat Memory used by query: 0 quota memory audit 16777216 quota memory query 1048576 quota audit [1] allowed = 0 denied = 1024 unmatched = 1024 100 acl write path="/etc/oracle/tnsnames.ora" audit 1 100 allow task.uid = 1002 200 deny ``` ## Writing to the file as a DBA User Using the DBA user account, content will now be added to the designated file. This action should be permitted under the current rule set. It's important to observe that the DBA user possesses write privileges to this specific file. ``` dba@debian:-S$ ls -1 /etc/oracle/ total 4 -rw-r--r-- 1 dba oracle 118 Jan 23 21:42 tnsnames.ora dba@debian:~$ echo 'production=(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp) (HOST=db.corp) (PORT=1630)) (CONNECT_DATA= (SERVICE_NAME=intranet.corp)))' > /etc/oracle/tnsnames.ora dba@debian:-$ cat /etc/oracle/tnsnames.ora production= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=db.corp) (PORT=1630)) (CONNECT_DATA= (SERVICE_NAME=intranet.corp))) ``` ## Trying to write to the file as superuser Due to a specifically crafted policy denial rule, the superuser is prevented from writing to the file. Consequently, even with superuser privileges, the write operation is unsuccessful. ``` root@debian:~# ls -1 /etc/oracle/ total 4 -rw-r--r-- 1 dba oracle 118 Jan 23 21:43 tnsnames.ora root@debian:~# echo "root was here” > /etc/oracle/tnsnames.ora bash: /etc/oracle/tnsnames.ora: Operation not permitted root@debian:~# cat /etc/oracle/tnsnames.ora production= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=db.corp) (PORT=1630)) (CONNECT_DATA= (SERVICE_NAME=intranet.corp))) root@debian:~# id uid=0 (root) gid=0 (root) groups=0 (root) ```