Don't run start-tor-browser unconfined from torbrowser-launcher: we have a dedicated profile for it, let's use it.
Complete AppArmor profiles update according to new XDG-compliant paths.
torbrowser-launcher must not be allowed to start itself unconfined.

This is dangerous, as it basically allows that script to escape its
AppArmor sandbox. This also seems to be useless.
Explicitly run Tor with its own AppArmor profile.

Commit 04b24660 changed the way Tor is run, from Px to rix.

Px exec's to profile that matches executable name, with environment
variable scrubbing. rix makes the child process inherit the current
process' confinement. Given we ship a `torbrowser.Tor.tor` profile,
we'd better use it than inherit the browser's confinement.
AppArmor: allow start-tor-browser to run some programs it needs.

These might be needed only when using the 4.x branch of TBB. Or, they were
always needed, but we didn't notice as torbrowser-launcher was apparently
running start-tor-browser unconfined.
Hide AppArmor log about torbrowser-launcher trying to read the Python interpreter.

Oh well, this script doesn't really need to read the interpreter that's
running it.
Allow Firefox to open TCP connections on systems with networking AppArmor mediation.

This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.
Allow Firefox to use make dbus calls, on systems with dbus AppArmor mediation.

This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.
Make AppArmor logs silent about Firefox trying to read /etc/machine-id.

This was done recently for /var/lib/dbus/machine-id, and Firefox apparently
falls back on /etc/machine-id if it cannot read the former, so this change
should make things more consistent.
AppArmor: give back read access on /etc/mailcap to Firefox.

This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.

This profile gives access to other kinds of file association, e.g.
the .desktop files found in /usr/share/applications/, so one wonders
why /etc/mailcap should be treated differently.
Drop AppArmor rules that are duplicate of ones found in abstractions we include, again.

I have done this already in commit 8db75b7c0. The commit message documented why.
So, this very commit is partially reverting commit 04b24660, that made the
opposite change for reasons that are unknown to me. Yay.
AppArmor: give back read access on /usr/share/gnome/applications/ and /usr/share/gnome/applications/kde4/ to Firefox.

These are places where more .desktop files, that Firefox uses for filetype
association information, can be found on some systems, e.g. Debian unstable.

This is why I have added these rules in commit d033d07e. So, I'm reverting
commit 04b24660, that made the opposite change for reasons that are unknown
to me.
Make format of recently added comments consistent with existing ones.
AppArmor: enable Firefox to use GStreamer, again.

I've added these rules in 9d38e775 already. Now, commit 04b24660 made the
opposite change, for reasons that are unknown to me, while at the same time it
added direct access to sound devices, which seems inconsistent. So, I'm
reverting to the previous state.

If these rules are not consensual, let's discuss them instead of silently
dropping them. Thanks in advance.
Remove probably useless commented out AppArmor rules.

These rules are mostly duplicates from ones that are already in the `fonts`
abstraction, that we transitively include, so it's unclear to me when they
may be needed.

Note that the only difference between the abstraction's rules and these ones is
the "k" access granted on /var/cache/fontconfig/, which feels odd:  even if
a non-root user is allowed to do that, none of my other confined
fontconfig-using applications need that, so I would be surprised if Firefox used
fontconfig in a way that requires locking that directory. Still, if I'm shown
rejection logs that show it's needed, then I'm happy to add it back... and then,
perhaps it will make more sense to push it to the upstream fonts abstraction.
AppArmor: allow Firefox to get entropy from @{PROC}/sys/kernel/random/uuid.

First, note that this file returns a different uuid each time it's read.

I'm not sure what Firefox does when it can't get a random UUID from there. If it
falls back to a fixed value, this might have problematic security implications:
randomness is sometimes useful for security purposes. The only place I could
find this file being used in the Firefox source tree is actually in the
`arc4_seed_proc_sys_kernel_random_uuid` function. If that's really why Firefox
tries to access this file, then I don't think we should block it.

I've not seen that file being accessed by Firefox personally. But given
troubadoour added it, and it can be found in the Firefox source code, with the
above reasoning in mind, it seems that the safest thing to do is to allow
Firefox to get the randomness it needs.
AppArmor: allow Firefox to learn how many CPU cores are present.

This was added in commits ace00d646 and a3908af8 already. Then, commit 04b24660
made the opposite change for reasons that are unknown to me.

Firefox can optimize things a bit depending on this information, which does not
seem terribly critical, and can probably be gathered by other means anyway,
given the current profile.

In the Firefox source code, this file is used in the PR_GetNumberOfProcessors
function, that itself is used e.g. in image/src/RasterImage.cpp to make use of
all available CPUs. Now, if someone shows that this information is leaked
on the network, and cannot be retrieved by other means given the same threat
model, then possibly it'll make sense to block this access... or to suggest
to the Tor Browser people to patch it out and always use one core only,
which would solve the (potential) problem also for people not using AppArmor.
Document the consequences of including the "audio" AppArmor abstraction.
AppArmor: add support for Tor Browser 4.x's paths.
AppArmor: allow Firefox to read processes and tasks' stats.

This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.

stat files are used in the JiffiesSinceBoot function
(xpcom/ds/TimeStamp_posix.cpp), which is used to compute process lifetime.
The consequences of blocking this access are unclear to me: it might plug issues
wrt. anonymity that the Tor Browser team would have missed (ask them?), but it
can as well introduce security issues by forcing Firefox to downgrade to worse
sources of information. If crypto is in play there, we would be playing
a dangerous game by blocking Firefox from accessing this information.