# Monty Hardening: AppArmor & Seccomp

This document describes optional OS-level hardening for the Monty execution lane.

Monty already limits capabilities at the interpreter level.
AppArmor/seccomp provide **defense in depth**.

---

## Threats Addressed

- Interpreter escape via implementation bug
- Unexpected syscall usage
- Accidental filesystem or network access

---

## Recommended AppArmor Profile (Conceptual)

Allow:
- read-only access to Python runtime
- memory allocation
- basic syscalls (read, write, exit)

Deny:
- file creation
- network syscalls
- process creation
- mount, ptrace, ioctl

Example sketch:

````

profile threegate-monty flags=(attach_disconnected) {
network deny,
file deny,
capability deny,
mount deny,
ptrace deny,

/usr/bin/python3 ixr,
/usr/lib/** r,

deny /** w,
}

```

(Exact paths depend on distro and container image.)

---

## Seccomp Strategy

If using Docker:

- Start from Docker default seccomp profile
- Remove:
  - `clone`
  - `fork`
  - `execve`
  - `socket*`
- Allow only:
  - memory, signal, exit, basic I/O

---

## When to Enable

- Multi-user environments
- Long-running services
- High-assurance deployments

For local, single-user research systems, Monty’s interpreter restrictions may be sufficient.

---

## Summary

Monty does not *require* OS sandboxing, but benefits from it.
This layer is optional, not foundational.