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_tor
profile; weird - in some cases (e.g. bridge mode with a correct clock), failure to rename
torrc
is 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 sincetorrc
still hasDisableNetwork 1
and 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.