Bug #9537
Fix torrc renaming with hardened AppArmor policy
100%
Description
On current bugfix/8007-AppArmor-hardening, some use cases that require Tor Launcher (and in turn, that need to rename torrc and replace it) fail, as shown by failures in bridge mode in time_syncing.feature.
Preliminary analysis:
- there’s no AppArmor denial log in dmesg; but it works just fine both if AppArmor is disabled, and when adding
flags=(complain)to thesystem_torprofile; weird - in some cases (e.g. bridge mode with a correct clock), failure to rename
torrcis not fatal: tor is still successfully configured via the control port, and can thus bootstrap — but if tor is restarted, e.g. because of a wrong clock, then it can’t bootstrap sincetorrcstill hasDisableNetwork 1and lacks the PTs configuration
It might have something to do with the weird AppArmor userspace (with WIP patches for improved alias support) we’re shipping in Tails/Wheezy => could be worth retrying in Tails/Jessie, or in Tails/Wheezy with Jessie’s AppArmor userspace backported for Wheezy.
Subtasks
History
#1 Updated by intrigeri 2015-06-06 09:47:05
intrigeri wrote:
> It might have something to do with the weird AppArmor userspace (with WIP patches for improved alias support) we’re shipping in Tails/Wheezy => could be worth retrying in Tails/Jessie, or in Tails/Wheezy with Jessie’s AppArmor userspace backported for Wheezy.
And indeed, manually recompiling the profile with apparmor_parser -r -K -O old-alias /etc/apparmor.d/system_tor seems to fix the problem.
#2 Updated by intrigeri 2015-06-06 12:40:44
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
Seems to be fixed with backported 2.9.
#3 Updated by intrigeri 2015-07-18 08:00:28
#4 Updated by intrigeri 2015-07-18 09:18:29
- Status changed from In Progress to Resolved
- Assignee deleted (
intrigeri) - Target version deleted (
Tails_1.5) - % Done changed from 10 to 100
- Type of work changed from Research to Code
Indeed, time_syncing.feature now passes just fine.