Tails

#1 Updated by intrigeri 2018-05-21 13:41:11

• blocks Feature #15139: Core work 2018Q2: Foundations Team added

#2 Updated by intrigeri 2018-05-21 13:41:19

• related to Bug #15395: Enigmail & AppArmor: Cannot get key from keyserver after finding it added

#3 Updated by intrigeri 2018-06-16 07:41:19

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10
• Feature Branch set to bugfix/15602-efail

#4 Updated by intrigeri 2018-06-16 08:17:38

• % Done changed from 10 to 50

Fixed on the topic branch.

#5 Updated by intrigeri 2018-06-16 08:21:18

• Assignee changed from intrigeri to segfault
• QA Check set to Ready for QA

Same as Bug #15602.

#6 Updated by segfault 2018-06-16 15:08:30

• QA Check changed from Ready for QA to Info Needed

I’m not sure if removing this (incompletely implemented) feature is the best solution. Couldn’t we fix this by adding an AppArmor rule which allows Thunderbird access to its private tmp directory? Or don’t you think that the private tmp makes sense at all? I verified that, as indicated in the comment, decrypted and opened attachements are indeed saved in this tmp directory, and I think it makes sense to not put these in /tmp, which other apparmored applications have whitelisted, but in the private tmp, which other apparmored applications are not able to access.

#7 Updated by segfault 2018-06-16 15:15:16

• Assignee changed from segfault to intrigeri

#8 Updated by intrigeri 2018-06-16 17:22:04

• Assignee changed from intrigeri to segfault
• QA Check changed from Info Needed to Ready for QA

> I’m not sure if removing this (incompletely implemented) feature is the best solution. Couldn’t we fix this by adding an AppArmor rule which allows Thunderbird access to its private tmp directory? Or don’t you think that the private tmp makes sense at all? I verified that, as indicated in the comment, decrypted and opened attachements are indeed saved in this tmp directory, and I think it makes sense to not put these in /tmp, which other apparmored applications have whitelisted, but in the private tmp, which other apparmored applications are not able to access.

I totally agree that would be best.

Now, some context:

• At some point we had a sponsor deliverable about migrating to Thunderbird; when we realized the timeline of security updates in Debian conflicted with our release schedule, we decided that this deliverable required confining Thunderbird with AppArmor.
• Therefore, Thunderbird was confined with AppArmor. It took ages because while those who were responsible for the sponsor deliverable did some preliminary work, it was never finished and I ended up spending countless hours polishing it to make it releasable.
• That preliminary work included, for some reason, raising the bar higher than required initially, with this custom $TMPDIR thing. As we can see here, that part was never polished and now we realize that it breaks real use cases.
• The AppArmor policy for Thunderbird is very relaxed currently; we’ve been discussing for a while if we wanted to make it stricter (and after years of discussion elsewhere, Bug #11964 was created).

So now I’m focusing on making things work in the simplest possible way. Given the above history, I’m not comfortable with hardening improvements that add complexity via a bigger delta that in the end I have to maintain. Now, if someone takes responsibility for this area of Tails, decides they want to harden things further at the cost of some additional complexity and maintenance work: by all means, fine by me :) But that won’t be on the Foundations Team’s plate IMO.

All this being said: I very much appreciate your attention to detail here! :)

#10 Updated by intrigeri 2018-06-25 06:30:08

• Status changed from In Progress to Fix committed
• Assignee deleted (segfault)
• % Done changed from 50 to 100
• QA Check changed from Ready for QA to Pass

Merged into stable.

#11 Updated by intrigeri 2018-06-26 16:24:39

• Status changed from Fix committed to Resolved