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.
If torbrowser-launcher cannot write to stdout, e.g. because it was
started in the background and the controlling terminal has been closed
or because it was started from a desktop environment launcher whose
stdout has been closed, it crashes after updating the GnuPG key.
This is due to print() crashing the program if stdout isn't writeable
and the string to print contains a newline.
To work around the problem, split the strings containing newlines into
several calls to print().
See also the upstream bug at https://bugs.python.org/issue32345
intrigeri [Thu, 26 Oct 2017 11:16:58 +0000 (11:16 +0000)]
AppArmor: drop the usr.bin.torbrowser-launcher profile.
It's been broken since years and shipped in complain mode since 26 months.
It's now obvious that nobody cares enough about this profile to maintain it,
so let's drop it to avoid polluting system logs with tons of AppArmor messages:
with Linux 4.14, starting Tor Browser once triggers 27k+ such messages.
intrigeri [Thu, 26 Oct 2017 11:12:52 +0000 (11:12 +0000)]
AppArmor: grant access to mostly innocuous stuff Firefox tries to read.
I did not check in details why it needs that nowadays but this does not
increase the attack surface significantly, so let's allow it and don't
take the risk of breaking security critical stuff by denying it blindly.
If someone does the research and shows that it's safe to deny such access,
then we can do so.
AppArmor: allow the tor process to modify its data directory.
It's unclear to me why this is not needed _all the time_, but it does make sense
that at least in some circumstances, it needs to do that, e.g. to create
that directory.
Originally reported by Chris Lamb <lamby@debian.org> on
https://bugs.debian.org/876484.
With systemd (at least on current Debian sid), /run/shm is a symlink to
/dev/shm, so "owner /dev/shm/org.chromium.* rw," is enough. With sysvinit,
apparently things are set up differently (perhaps the symlinks are in the
opposite direction?) so Firefox tries to access /run/shm/org.chromium.*,
which was rejected.
Let's support both!
Thanks to gregor herrmann <gregoa@debian.org> for the bug report:
https://bugs.debian.org/874383
Note that this problem happens with pristine 0.2.8 profiles,
without the changes brought by my apparmor-e10s branch.