We already allow Firefox to send term signals to plugin-container;
this is the receiving counterpart.
This requires giving the Firefox profile a proper name (torbrowser_firefox)
because this:
signal (receive) set=("term") peer=/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox
… does not work.
Note to package maintainers
===========================
(This should probably be copied to the release notes.)
Due to the profile renaming, upgrading the
/etc/apparmor.d/torbrowser.Browser.firefox file requires special care. The best
option is probably to strongly recommend users to reboot their system after
this upgrade.
Other options I can think of have unacceptable consequences:
- if we unload the old profile from the kernel, we will leave any already
running Tor Browser's Firefox executable unconfined, which is an unacceptable
violation of the user's security expectations;
- if we don't unload the old profile from the kernel, surprising behaviour will
happen such as:
- any already running Tor Browser's Firefox executable will be left confined
under the old profile which won't play well with new rules that have
peer=torbrowser_firefox;
- unpredictable behavior when a new Tor Browser is started, because two
profiles matching the Tor Browser's Firefox executable are loaded.
#include <tunables/global>
#include <tunables/torbrowser>
-/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox {
+@{torbrowser_firefox_executable} = /home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox
+
+profile torbrowser_firefox @{torbrowser_firefox_executable} {
#include <abstractions/gnome>
# Uncomment the following lines if you want to give the Tor Browser read-write
# owner @{PROC}/@{pid}/fd/ r,
# owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/tmp/mozilla-temp-* rw,
+ signal (receive) set=("term") peer=torbrowser_firefox,
+
deny /etc/host.conf r,
deny /etc/hosts r,
deny /etc/nsswitch.conf r,