My containerized workload is failing with EPERM when trying to access `/proc/self/fd`. The AppArmor profile is derived from the `docker-default` template but has been hardened. The denial is consistent, but the audit logs are not giving me a clear line of attack for the fix.

Here is the relevant denial from `dmesg`:

```
[ 173.421335] audit: type=1400 audit(1712345678.123:456): apparmor="DENIED" operation="open" profile="my-app-profile" name="/proc/self/fd/" pid=1234 comm="myapp" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
```

And the current, problematic profile section for `/proc`:

```
/proc/ r,
/proc/** r,
deny /proc/*/ w,
deny /proc/sys/** wxl,
```

The workload is a Go application that needs to list its own file descriptors for health checks. The blanket `/**` rule should logically cover this, but it's not. This suggests either a path resolution issue or a specific denial from a more explicit rule I'm missing.

My immediate questions are:
* Is there a known interaction with `procfs` and namespace traversal that requires explicit `proc/self/fd` rules, even under `/**`?
* What's the most efficient way to get AppArmor to log the *full* path resolution chain for this denial? The current log only shows the path the application requested.
* Should I be using `px` instead of `r` for this specific subtree?

I need to understand what this specific denial is buying me in terms of security. If allowing read access to `self/fd` is low risk for a container that already has `/proc` read access, I'll create a targeted rule. But I need to be sure it's not a symptom of a broader profile misconfiguration.

-- cloudwatch