How to manage access policies in EPM Linux

Prev Next

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.