Bridge-Relay HOWTO wiki update for distros with apparmor, escalade log level when transport plugin process is killed

The bridge howto wiki instructions we currently have will not apply in Debian Buster or Bullseye (because of apparmor, and I assume the effect is the same on any distro with apparmor enabled).

Basically, the package Tor from deb.torproject.org comes with apparmor settings in /etc/apparmor.d/abstractions/tor that includes /usr/bin/obfs4proxy Pix, , but in case obfs4proxy executable is installed at a different path, it won't work:

audit[2994]: AVC apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" fsuid=107 ouid=0

kernel: audit: type=1400 audit(1630685584.124:19): apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" >

Also, Tor will not complain about it in the log if set to default notice level. If you switch to info :

[info] process_exec(): Starting new process: /usr/local/bin/obfs4proxy

[info] launch_managed_proxy(): Managed proxy at '/usr/local/bin/obfs4proxy' has spawned with PID '1856'.

These should be set to warn level I guess?

The simple fix is to edit /etc/apparmor.d/abstractions/tor and add/edit the obfs4proxy path if different from /usr/bin/obfs4proxy (which is the default) and reload apparmor service. We should add this extra step in the bridge relay wiki howto and explain that it is necessary if the pluggable transport is installed in a different path than /usr/bin/$transport in addition to the libcap2-bin step and NoNewPrivileges=no step in tor@default.service and tor@.service.