---
title: "How to manage access policies in EPM Linux"
slug: "how-to-manage-access-policies-in-epm-linux"
updated: 2026-11-03T14:48:18Z
published: 2026-11-03T14:48:18Z
canonical: "docs.senhasegura.io/how-to-manage-access-policies-in-epm-linux"
---

> ## 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 access policies in EPM Linux

This document provides a step-by-step guide to setting up an access policy in EPM Linux.

Creating policies ensures that rules are applied to the shell, software, script and parent and child process controls, preventing users from bypassing privileges. System administrators can create policies, control files and folders, set permissions, create aliases, manage environment variables, control directories and files and perform other actions based on these policies.

Policies are segregated into two levels:

1. **General** (all devices).
2. **Devices** (specific devices).

## Important

- Kernel policies control Access Control Lists (ACLs), restricting or allowing access at the Linux kernel level. The order of the policies is crucial, as it determines their priority, and prohibitive policies have the potential to cause serious damage to the device. It is essential to use absolute paths when creating rules. To discover binary paths and symbolic links, use the `which`, `readlink` or `ls -la` commands.
- Rules apply to both user and script execution.
- EPM Linux does not grant permission to a directory or file to a user if the operating system does not allow access.

## Requirements

1. To use access policies, you need to know the path of the binary within your Linux workstation. To do this, follow these steps:
2. Access the Linux terminal.
3. Type `which [command]` to find the path of the binary.
4. For example, if you want to find a symbolic link, use one of two commands:
  1. `readlink [command path]`.
  2. `ls -la [command path]`.

          Attention

          

- When creating rules, make sure you use the absolute path.
- These rules also apply to commands executed in scripts. EPM Linux has a security module that complies with policies in any scenario and makes no distinction between user or script executions.

## Create a general access policy

Pay attention to the following points:

- When filling the **Guideline** field, pay attention that, if the command is already embedded in the user's shell, EPM Linux won’t perform the search to execute the command directly by the system. Thus, commands embedded in the shell won’t be filtered by the access policy. To check which commands are embedded in the shell, use the Linux terminal and type **help**.
- Pay attention when changing or filling the **Checker (path or executor),** any failure to fill in this field or even filling it in incorrectly can lead to the device becoming completely unusable. Follow the CaitSith syntax rules.
- The first rule added has priority over any rules inserted afterwards. If you create a rule that allows the execution of the binary and then add another rule to block the execution of the same binary, the first rule will be considered and the second will not.

1. In Segura™, 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. On the **Segregation** screen, select the type of policy, in this case **General**.
5. In the **Access policy** registration form, fill in:
6. On the **General** tab:
  1. **Policy name**: define a name that is easy to identify.
  2. **Status**: if active, the policy will be applied to devices.
  3. **Guideline**: select a policy type.
  4. **Checker (path or executor):** fill in the directory path (for example: `path=“/usr/bin/ls”`) or the executor for symbolic links (for example: `exec=“/etc/alternatives/vim”`). To get the path, type which [command] and to validate that it is a symbolic link, type `ls -la [command].`
  5. **Enable auditing?:** mandatory field and active by default. Allows auditing of actions taken.
  6. **Include general deny rule?**: if this option is checked, no user of the Linux workstation will be able to execute anything that is not allowed by the access policy. Otherwise, all users of that workstation will be allowed to run everything except what is blocked by the rule.
  7. To add a new rule, click **Add** and fill in the fields in the table.
    1. **Allow or block**: choose whether the registered policy allows or blocks access for the user or group.
    2. **Rule text:** fill in a rule in the format of the policies in CaitSith. For example, for `users: task.uid=“user”`. For groups: `task.gid=“group”`. You must use the user's primary group.
    3. To validate that the policy has been added to the device, type the command cat /sys/kernel/security/caitsith/policy in the terminal.
  8. Click on **Continue**.
  9. In the **Application** tab:
    1. **Enable auditing**: select **Yes** to enable session auditing.
    2. **Enable session recording**: select **Yes** to enable session recording.
    3. **Include general deny rule**: select the checkbox if you want to include a general deny rule for the application.
    4. To add a new application, click **Add** and fill in the fields:
      1. **Application path**: enter the full path of the application on the workstation. For example `etc/vim`.
      2. **Symbolic link:** select whether the path indicated is a symbolic link.
    5. To add a new permission, click **Add** and fill in the fields:
      1. **Permission**: select the type of permission action, **Block** or **Allow**.
      2. **Type**: select the type of permission, **Group** or **User**.
      3. **Name**: enter a name for the permission.
  10. Click **Continue**.
  11. In the **Directory and file control** tab:
    1. To add a new permission, click **Add** and fill in the fields:
      1. **Permission**: select the action: Execute, Read or Write.
      2. **Directory or file**: indicate the directory or file that will receive this new permission.
      3. **User**: enter the username that will be linked to this permission.
    2. To add a new blocking rule, click **Add** and fill in the fields:
      1. **Permission**: select the action: Execute, Read or Write.
      2. **Directory or file**: indicate the directory or file that will receive this new permission.
      3. **User**: enter the username that will be linked to this permission.
  12. Click on **Continue**.
  13. In the **Aliases** tab:
    1. To register a new alias, click **Add** and fill in the fields:
      1. **Alias**: this is actually a “nickname” for a Linux command, so you can enter a text that is simpler and easier to remember. Enter the text in this field.
      2. **Command**: enter the command that will be executed when the alias is used.
    2. To check the aliases created, type `cat /etc/senhasegura/aliases` in the terminal.
  14. Click on **Continue**:
  15. In the **Environment variables** tab:
    1. To register a new environment variable, click **Add** and fill in the fields:
      1. **User name**: enter the user name that will be linked to this environment variable.
      2. **Variable name**: enter the name of the environment variable.
      3. **Variable value**: enter the value of the environment variable.
  16. Click on **Continue**.
    1. On the **Review** tab, review the registration of the rule and click **Save**.

## Create an access policy for a device

The process for creating an access policy for a specific device follows the same flow as the general policy, with the addition of the Devices tab, where it is possible to indicate the device where the rule should be applied So, on the **Access policy registration** form, on the **Devices** tab, fill in the fields:

1. To register a new environment variable, click **Add** to open the **Devices** modal.
2. In the **Devices** modal, select the devices you want to link to the rule.
3. Click **Add**.
4. Click on **Continue**.
5. On the **Review** tab, review the registration of the rule and click **Save**.

          Caution

          

- All commands that pass through a filtering process will be logged. This includes rules defined to allow execution in CaitSith access policies or rules for `sudo`.
- Avoid reusing existing policies, rather create new ones. Constantly editing existing policies can cause errors in the policy being created.
- Directory and file permissions are:
  - **Execute**: does not allow you to execute a file or access a directory.
  - **Write**: does not allow you to edit a file or modify the contents of a directory.
  - **Read**: does not allow you to view or list files and sub-files and/or sub-directories.