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/issue32345Closes#298
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.
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.
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.
Except the official site, there're only 3 working mirror in current
mirror list. So it's really necessary to update the list now.
Got the latest list from:
- https://www.torproject.org/getinvolved/mirrors.html.en
And only keeps https links for security sake.
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.
We will later remove credentials plugin-container doesn't need, in order to
confine it more strictly. Such effort would be worthless if we kept inheriting
the permissions we grant the parent Firefox process.
abstractions/base allows access to /proc/meminfo already, so this doesn't leak
much more information. I can't be sure by looking at the code, but I would
not be surprised if Firefox needed more info about available memory
to manage it pool of content rendering processes, when e10s is enabled.
As of Tor Browser 7.0.1:
* /dev/dri/: we block access to the DRI nodes, so listing
them would be useless
* net/route: seems risky as it can leak information about IPs used on the LAN;
Tor Browser seems to works perfectly without such access, so let's not
grant it to be on the safe side
* CPU maximum frequency:only used to optimize VP8/VP9 encoding
* CPU cache size: seems unused
