Sometimes the executable path just isn't enough. For instance, for the
tor-launcher filter the executable is the unconfined firefox executable,
also used by our chroot browsers. So let's be a bit more restrictive.

While we're at it, make it possible for a single client to match
multiple filters -- otherwise the rules for which single filter will be
selected in case multiple matches will just complicate things. So, if we
want, we can now refactor common parts of filters. :)

128 bytes is not enough for e.g. "SETCONF Bridge=..." when using obfs4.

And refactor some code while we're at it.

But they will not be able to do anything except PROTOCOLINFO,
AUTHENTICATE and QUIT, which is not very interesting.

This simplifies client configurations and assumptions made in many
applications that use Tor's ControlPort. It's the exception that we
connect to the unfiltered version, so this seems like the more sane
approach.

I.e. make it possible to pass the listen port, and Tor control
cookie/socket paths as arguments.

Will-fix: #6742

This is just much less complex code-wise, and the procfs API is likely
more stable than the output of aa-status any way.

They're still in complain mode, cause enforcing them breaks the
applications (when they read from tor-controlport-filter's socket, they
get empty data and fail). And there are still some audit log entries
generated for onionshare-gui, for reasons I do not yet understand. There
are a few other questions in comments.

However, this is actually solving the blocking issue we have with the
stub AppArmor profiles flooding the journal. Fixing these AppArmor
profiles so we then can enable them is more like a bonus.

Fix-committed: #11853, #11850

Using /proc/pid/cmdline is not secure since it can be trivially set
with, for instance:

    exec -a "pwned" sh -c 'cat /proc/$$/cmdline'

The /proc/pid/exe symlink is not good enough for scripts (since it will
point to the interpreter, not the script) so let's instead use
AppArmor's in-kernel solution for determining executable paths. We
fallback to /proc/pid/exe for unconfined processes, which leaves us with
only unconfined scripts not being supported by tor-controlport-filter.
However, profiles in complain mode is still good enough, so a trivial
stub profile in complain mode is enough, which is exactly what we do for
onionshare and onioncircuits.

Fix-committed: #11846

Fix-committed: #11449

Thanks to u for the phrasing!

Fix-committed: #11798

 Conflicts:
	debian/changelog

 Conflicts:
        config/APT_snapshots.d/torproject/serial

 Conflicts:
	config/APT_snapshots.d/torproject/serial

 Conflicts:
	config/APT_snapshots.d/torproject/serial

Fix-committed: #11832