Hi everyone. I've been reading through the subforum archives, and I appreciate all the technical examples shared here. I'm still trying to map a lot of this to compliance requirements.

I'm working on a project where an agent needs to read configuration from various protected directories (like `/etc/app/` and `/opt/vendor/configs/`), but it absolutely must not write there. It should only be allowed to write temporary data, exclusively to `/tmp`. The principle is "read many places, write only to a volatile scratch space."

I drafted an AppArmor profile based on the patterns I've seen, but I'm nervous about the implications. My main questions are:

1. Does blocking all writes except to `/tmp**` effectively cover things like symbolic link and hard link creation? Or do I need explicit `deny` rules for `link` and `symlink` syscalls elsewhere?
2. From an audit trail perspective, if the agent *attempts* to write outside `/tmp`, will the default logging show the full path it tried to access, or just the syscall? I need to prove attempted violations for our internal reports.
3. Are there any known pitfalls with this "allow reads everywhere" approach? For instance, could reading from `/proc` or `/sys` inadvertently expose sensitive data the agent shouldn't have? I'm thinking about GDPR and the principle of data minimization.

Here's my current draft profile. I've tried to make the write deny rules as broad as possible.

```
#include

profile agent-profile {
#include

# Allow reads almost everywhere
/** r,

# Explicitly allow writes only in /tmp
/tmp/** wl,

# Explicitly deny writes everywhere else
deny /** wl,
}
```

I'm specifically using `wl` for the write links to allow following symlinks for writes within `/tmp`. Is that correct, or does it introduce a risk?

Any guidance on tightening this for compliance would be deeply appreciated. I want to make sure the audit trail is solid.

- Connie