use /@{PROC}/@{PID}

[idk-r-n]

Programs don't need to be able to information of other processes in /proc

[krathalan]

@{pid} doesn't fix the issue. See this (archived) discussion from 2016: https://bugs.launchpad.net/apparmor/+bug/1546825

If you look at what @{pid} actually does, look at /etc/apparmor.d/tunables/kernelvars:

   9   │ # This file should contain declarations to kernel vars or variables
  10   │ # that will become kernel vars at some point
  11   │ 
  12   │ # until kernel vars are implemented
  13   │ # and until the parser supports nested groupings like
  14   │ #   @{pid}=[1-9]{[0-9]{[0-9]{[0-9]{[0-9]{[0-9],},},},},}
  15   │ # use
  16   │ @{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9
       │ ][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9],[1-4][0-9][0-9][0-9][0-9][0-9][0-
       │ 9]}

Also look at this comment by an AppArmor developer from 1 year ago on this open issue: https://gitlab.com/apparmor/apparmor/-/issues/158#note_552003637

While there isn't a distinction atm, the plan is to move these to being kernel vars so we very much want to have the semantics for that set in policy. The whole point of introducing the vars the way we did was to front run the change coming to the kernel so that policy was ready for it.

I will switch to using @{pid}, as hopefully this will be fixed/added eventually, but ATM doesn't do anything.

[idk-r-n]

I didn't realize at the time that @{pid} didn't actually improve anything. I guess I'll need bubblewrap or something to manage /proc.

[idk-r-n]

Using bwrap with --proc /proc seems to be an easy solution to this. This might not be relevant to this repo, but I thought it might be worth mentioning.