intrigeri [Sun, 31 Mar 2019 15:36:57 +0000 (15:36 +0000)]
AppArmor: grant permissions needed for audio support.
It's 2019. Users want to watch videos in Tor Browser. Having to edit files and
run commands as root is not a realistic expectation for Tor Browser users.
intrigeri [Sun, 31 Mar 2019 14:33:45 +0000 (14:33 +0000)]
AppArmor: drop the profile dedicated to Web Content processes.
Before Firefox 60, Web Content processes were instances of a dedicated
binary (plugin-container). But since Firefox 60, the Web Content processes are
instances of the very same executable as the parent Firefox process,
which makes it impossible to apply a different AppArmor policy to:
- Web Content processes, that should ideally be more strictly confined
- the new parent Firefox process that's spawned while restarting
during a self-upgrade of Tor Browser
As a result, the new parent Firefox process that's spawned while restarting
during a self-upgrade of Tor Browser runs under the torbrowser_plugin_container
profile, i.e. more strictly confined than it should be, which breaks all kinds
of things.
A Firefox release manager tells me there's no plan to give Web Content processes
a dedicated binary again; let's give up and go back to confining the entire
browser under one single AppArmor profile, and rely on Firefox' own sandboxing
systems to protect itself against rogue Web Content processes.
5 years back Debian introduced apt as the new “pleasant for end users” tool over apt-get. The newer apt command works on all currently supported Ubuntu and Debian releases. See https://itsfoss.com/apt-vs-apt-get-difference/
intrigeri [Sat, 18 Aug 2018 19:23:13 +0000 (19:23 +0000)]
AppArmor: adjust Firefox binary path for Tor Browser 8.0a10.
At this point it seems unlikely that the develop branch will be released
before Tor Browser 8.0 so here we go, let's get ready.
Note that I could have written firefox{,.real} instead, to support both Tor
Browser 7.5 and 8.0, but then we would have to open the profile more broadly so
the new shell wrapper installed as "firefox" by Tor Browser 8.0a10 can do its
job. This does not seem worth the hassle and will be fine as long as this new
torbrowser-launcher is released approximately at the same time as, or after, Tor
Browser 8.
Micah Lee [Fri, 23 Mar 2018 22:42:11 +0000 (15:42 -0700)]
Fixed various issues related to sig verification. Now if the verification fails, it saves a backup. And it uses gpg2 to refresh the keyring instead of gpg1, which did nothing.
intrigeri [Mon, 29 Jan 2018 08:01:12 +0000 (08:01 +0000)]
AppArmor: give the tor profile a stable name.
This will allow us to handle upgrades more nicely in the future,
e.g. when the executable path changes. Besides, this makes the output of
aa-status and logs much easier to grasp.
Note to packagers: exactly as for the similar change applied to the Tor
Browser's Firefox profile, please consider recommending users to reboot their
system after the upgrade that applies this change.
intrigeri [Mon, 29 Jan 2018 06:43:43 +0000 (06:43 +0000)]
AppArmor: allow plugin-container to receive term signals from the parent Firefox process.
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.