# Target and control policies

> Group resources into target policies and use control policies to decide which sudo commands and Windows programs are allowed, refused or sent for approval.

URL: https://docs.ironchip.com/en/pam/administracion/politicas/

PAM policies are pieces that an [access](https://docs.ironchip.com/en/pam/administracion/accesos/) names: **target policies** say which machines it reaches and **control policies** say what can be done as root once inside. This page explains how to create them. It is for whoever administers privileged access.

The conditions for getting in (device, safe zone, factors and approval) are not here: they are the access's [authentication policies](https://docs.ironchip.com/en/identidad/conceptos/politicas/), and approval is defined in [approval policies](https://docs.ironchip.com/en/pam/administracion/aprobadores/).

## Target policies

A target policy is a named set of machines, such as `Production Linux`. An access names it just as it names a factor group, so two teams can reach the same machines under different conditions.

### Create a target policy

1. Go to **PAM > Hosts > Target policies** and click **Add target policy**.

   [Image: Target policies page with each policy, its machines and the accesses that name it]

2. Enter **Name** and, optionally, **Description (optional)**, for example `All production Linux servers, in Madrid and on AWS`.
3. In **Machines**, select the machines. They are grouped by site, and a policy can mix sites.
4. Click **Add target policy**.

The policy gives nobody access until you name it in an access.

### Change or delete it

- **Options > Edit policy** changes the name or the machines. The accesses that name it reach the new machines as soon as you save, and stop reaching the ones you remove.
- **Options > Remove policy** deletes it. The machines stay. It cannot be deleted while any access names it: the **Accesses** column shows which ones.

## Control policies

A control policy says what a person connected through Ironchip can run as root:

- On **Linux**, each `sudo` command. The machine asks Ironchip through the [agent](https://docs.ironchip.com/en/pam/administracion/agente/) after its own `sudoers` rules have said yes, so a policy can only take permissions away, never grant them.
- On **Windows**, the programs that the account the person signs in with can open, which the agent enforces with AppLocker.

Without the agent on the machine, control policies are not applied on it.

### The default policy

Every company has **All allowed**, Ironchip's own: everything can run and the machine's own rules decide. It comes selected in every new access and cannot be changed or deleted. To restrict, create another one.

### Create a control policy

1. Go to **PAM > Hosts > Control policies** and click **Add control policy**.

   [Image: Control policies page with each policy, its rules and the accesses that name it]

2. Enter **Name**, for example `Web operators`, and optionally a description.
3. In **Rules, in order**, add each rule with **Add rule**:
   - **Kind**: **Command (sudo)** or **Windows program**.
   - **Command**: the full command line as it would run, with the program's full path: `/usr/bin/systemctl restart *`. `*` matches anything, including spaces and slashes; `?` matches one character.
   - **Program or path**: the executable name, `powershell.exe`, which matches even if it is copied to another folder, or a path with `*` and Windows folder variables: `%PROGRAMFILES%\Tools\*`.
   - **Then**: **Allow**, **Refuse** or **Ask approvers**. With **Ask approvers**, choose the **Approval policy** that decides.
4. Order the rules with the arrows: **the first one that matches decides**.
5. In **Anything else**, choose what happens to anything that matches no rule. By default, **Refuse**.
6. Click **Add control policy**.

   [Image: Add control policy window with sudo rules that are allowed, refused and sent for approval]

An example for a team that restarts web services and reads their logs:

| #   | Kind           | Command or program                 | Then              |
| --- | -------------- | ---------------------------------- | ----------------- |
| 1   | Command (sudo) | `/usr/bin/systemctl restart nginx` | **Allow**         |
| 2   | Command (sudo) | `/usr/bin/journalctl -u nginx*`    | **Allow**         |
| 3   | Command (sudo) | `/usr/bin/apt install *`           | **Ask approvers** |
|     | Anything else  |                                    | **Refuse**        |

### How it is decided

- If an access names several policies, they are checked in the order you selected them and the first matching rule decides. If none matches, the strictest **Anything else** applies (refusing before asking for approval, and asking for approval before allowing).
- A command waiting for approval appears in [PAM > Approvals](https://docs.ironchip.com/en/pam/administracion/aprobadores/#commands-waiting-for-approval) and the person waits at the `sudo` prompt for up to 5 minutes. If nobody decides in time, it is refused.
- If nobody is connected to the machine through Ironchip, the command is refused. Commands that already run as root (uid 0) are not checked.
- If two or more people are connected with the same account, Ironchip cannot tell whose command it is and refuses it. Use [separate accounts](https://docs.ironchip.com/en/pam/administracion/cuentas/) for each team.
- On **Windows**, a refusal wins over an allow regardless of order, and a program cannot wait for approval (**Ask approvers** is not available). Refusing everything else still lets Windows and the installed programs run: it stops what the person brings in their own folders. With nobody connected, the account keeps every refusal from every access that reaches the machine, so the rules are in place before anyone signs in; with several people connected, the strictest rules apply.
- An access that names no control policy leaves the decision to the machine.

When you edit a policy that accesses name, the next command is already decided with the new rules.

## More information

- [Accesses](https://docs.ironchip.com/en/pam/administracion/accesos/): where these policies are named.
- [Approval](https://docs.ironchip.com/en/pam/conceptos/aprobacion/): how approval of accesses and commands works.