# Security Guide

`rtmn` runs Linux shell commands through Telegram. Treat an allowed Telegram chat as shell access to the configured Linux account.

## Core Rules

- Keep allowed chat IDs minimal.
- Run the service as a non-root Linux account.
- Use a different Telegram bot token for each server or concurrently running instance.
- Do not expose tokens in shell history, logs, tickets, or chats.
- Keep environment files owned by root with mode `0600`.
- Review audit logs and journal logs regularly.

## Account Permissions

The service account should have only the permissions needed for its operational role.

Not recommended:

```
User=root
```

Recommended:

```
User=<service-account>
Group=<service-account-group>
```

## Environment File Permissions

Environment files contain bot tokens.

Recommended permissions:

```
owner: root
group: root
mode:  0600
```

Verification commands:

```bash
sudo stat -c '%n %U %G %a' /etc/rtmn/env
sudo stat -c '%n %U %G %a' "/etc/rtmn/env-$INSTANCE"
```

## Token Isolation

Do not run multiple `rtmn` instances with the same bot token at the same time.

Problems caused by token reuse:

- Telegram long polling races
- Unpredictable message delivery
- Difficult incident analysis
- Larger blast radius if the token is exposed

## Audit Logs

Audit logs track command execution and rejected events.

For account-isolated installations, use a separate audit log path per instance.

```
/var/log/rtmn/ops/audit.log
/var/log/rtmn/app/audit.log
/var/log/rtmn/admin/audit.log
```

## Limits of Interactive Program Blocking

`RTMN_BLOCKED_INTERACTIVE` and the built-in denylist are convenience guardrails. They are not complete security boundaries.

The real security boundaries are:

- Telegram chat allowlist
- Linux execution account permissions
- sudoers policy
- File system permissions
- Server network access controls