Sandbox Tor Browser's content renderer processes more strictly
Since we have enabled Electrolysis (e10s), we confine these processes in exactly the same way as the parent Firefox process. I'm pretty sure they could be confined much more strictly, without impacting UX whatsoever. And while we're at it, maybe some permissions we currently grant to the parent Firefox process are not needed anymore, as it does less work.
Fix devel from FTBFS by downgrading torbrowser-launcher.
torbrowser-launcher 0.2.9 has entered sid and thus the APT snapshot
used by devel, and since our AppArmor profile patch does not apply, we
FTBFS. Updating the patch is the real fix, but is complex and will be
part of #12679.
Install current upstream Tor Browser AppArmor profiles + our custom patch (refs: #12679).
Taken from 894f2cb1474f78121d2da8cf954d2a23919666df in our
Tor Browser AppArmor profiles: update our custom patch (refs: #12679).
Taken from 3286cb1f342218e9bbb2638e1bdda99b2d2f0737 in our
- Silence denial of access to ~/.cache/fontconfig/.
- Allow innocuous access to /usr/share/applications/gnome-mimeapps.list to
#3 Updated by intrigeri about 2 years ago
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
I have something that Works On My Machine™. Up-to-date info about it can be found on https://github.com/micahflee/torbrowser-launcher/issues/278.
#6 Updated by intrigeri almost 2 years ago
- % Done changed from 20 to 30
The branch now passes
features/documentation.feature:4 features/localization.feature features/tor_enforcement.feature:15 features/tor_stream_isolation.feature:26 features/torified_browsing.feature features/unsafe_browser.feature locally. Next step: upstream my changes to tbl, and then wait for them to reach Debian sid, and then we can replace my hard-coded profiles in tails.git with a proper patch.
#7 Updated by intrigeri almost 2 years ago
- Type of work changed from Code to Wait
#9 Updated by intrigeri almost 2 years ago
#18 Updated by intrigeri over 1 year ago
- % Done changed from 30 to 40
My branch was merged upstream \o/ but I'm not sure how well it will work as-is (I had actually asked upstream to first merge something else so I could then update my branch on top of that).
I've sent a follow-up PR: https://github.com/micahflee/torbrowser-launcher/pull/310.
#23 Updated by intrigeri over 1 year ago
I'll request a first merge of this branch to fix #15270 as soon as some local test suite runs finish successfully, but I'm not done here yet: I want to do some more manual testing, ensure the plugin container profile is applied and e10s is enabled, look at AppArmor logs, and possibly backport some
deny rules from my last upstream PR to make the kernel logs less noisy.
#26 Updated by intrigeri over 1 year ago
I want to do some more manual testing, ensure the plugin container profile is applied and e10s is enabled, look at AppArmor logs, and possibly backport some
denyrules from my last upstream PR to make the kernel logs less noisy.
Done all this, will submit for QA once I've confirmed an ISO built from my (updated) branch behaves correctly.
#32 Updated by anonym over 1 year ago
- Status changed from In Progress to Fix committed
- Assignee deleted (
- % Done changed from 50 to 100
- QA Check changed from Ready for QA to Pass
Works for me! I found it a bit hard to track our patch's changes being split over the two profiles, but think I managed to in the end. :)