> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure AppArmor for charon

> Grant charon access to the Futurex PKCS #11 library, configuration, and log files, then verify AppArmor is no longer denying it.

On Ubuntu and other AppArmor distributions, charon runs under a confinement profile that does not permit reading the Futurex library or configuration from `/usr/local/lib/fxpkcs11` and `/etc/fxpkcs11`. Grant that access before configuring strongSwan.

<Note>
  Skip this section on a distribution that does not use AppArmor. On SELinux, grant charon equivalent access to the same paths instead. This guide does not provide an SELinux policy.
</Note>

## Create the local AppArmor override

```shell expandable lines wrap title="Shell" theme={null}
sudo mkdir -p /etc/apparmor.d/local

sudo tee /etc/apparmor.d/local/usr.lib.ipsec.charon > /dev/null << 'EOF'
/usr/local/lib/fxpkcs11/libfxpkcs11.so rm,
/usr/local/lib/fxpkcs11/PKCS11Manager rm,
/etc/fxpkcs11.cfg r,
/etc/fxpkcs11/ r,
/etc/fxpkcs11/* r,
/etc/fxpkcs11.log rw,
/etc/fxpkcs11.log* rw,
/tmp/fxpkcs11.log rw,
/tmp/fxpkcs11.log* rw,
/var/log/charon-debug.log rw,
EOF
```

<Warning>
  The file may already exist and be **empty**. An empty override parses cleanly and reloads without error, yet charon is still denied. Confirm the file has content before continuing.
</Warning>

```shell expandable lines wrap title="Shell" theme={null}
sudo wc -l /etc/apparmor.d/local/usr.lib.ipsec.charon
```

<Check>
  The count is 10, matching the rules above. If it reports 0, the `tee` command did not write; re-run it.
</Check>

## Reload the profile

```shell expandable lines wrap title="Shell" theme={null}
sudo apparmor_parser -r /etc/apparmor.d/usr.lib.ipsec.charon
```

## Verify AppArmor is no longer denying charon

This verification matters. If the override is missing or incomplete, nothing fails here — the problem surfaces several steps later as `load-token reply {success=no}` with no mention of AppArmor.

```shell expandable lines wrap title="Shell" theme={null}
sudo systemctl restart strongswan-starter
sleep 5
sudo dmesg | grep -i 'apparmor.*DENIED' | tail -20
```

<Check>
  The command returns no output, or no entries whose `profile=` names charon and whose `name=` points at a Futurex path. Any such line names the exact path that is still blocked — add it to the override and reload.
</Check>

If `dmesg` requires elevated access or returns nothing on your system, check the audit log instead:

```shell expandable lines wrap title="Shell" theme={null}
sudo grep -i 'apparmor.*DENIED' /var/log/syslog /var/log/audit/audit.log 2>/dev/null | tail -20
```