Project

General

Profile

Bug #11973

AppArmor profile for Thunderbird missing

Added by u 11 months ago. Updated 18 days ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
11/20/2016
Due date:
% Done:

50%

QA Check:
Dev Needed
Feature Branch:
icedove:tails/stretch tails:feature/11712-thunderbird
Type of work:
User interface design
Blueprint:
Easy:
Affected tool:
Email Client

Description

IMO, when we install Icedove from Debian, the AppArmor profile from the package should be installed and enforced by default. I can't see the file in /etc/apparmor.d nor when running sudo aa-status. Tested in 2.7 and 3.0 (feature/stretch).


Related issues

Blocked by Tails - Bug #11712: Have Icedove built from Stretch with our patchset applied in Tails 3.0 Resolved 08/24/2016
Blocked by Tails - Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments In Progress 11/19/2016
Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Confirmed 06/29/2017

Associated revisions

Revision e0b8ef9f (diff)
Added by anonym 5 months ago

Enable the feature-11712-thunderbird APT overlay.

This will install thunderbird 1:45.8.0-3+tails2 built for amd64 on
Debian Stretch. Naturally it is a first step for the Icedove →
Thunderbird migration as well. And this package contains an AppArmor
profile (unlike the Debian Jessie package).

Refs: #12242
Will-fix: #11712, #11973

These packages also has the patch from the following upstream ticket
applied:

https://bugzilla.mozilla.org/show_bug.cgi?id=1281959

We enable browser.download.forbid_open_with so the "Open with..."
option is hidden in the attachment download dialog, since
Thunderbird's AppArmor profile does not allow starting applications in
Tails.

Refs: #11964

Revision cc3b16ea (diff)
Added by intrigeri 5 months ago

Disable the Thunderbird AppArmor profile (refs: #11712, #12242, #11973, #11964).

The corresponding documentation is missing and I haven't seen this coordinated
with our tech writers:

I'd rather not break parts of the UX without a clear plan to explain
it to our users.

History

#1 Updated by u 11 months ago

  • Related to Bug #10750: Ship an AppArmor profile for Icedove in Tails added

#2 Updated by intrigeri 11 months ago

IMO, when we install Icedove from Debian, the AppArmor profile from the package should be installed and enforced by default.

This will be the case once we install the package from testing/sid, as the one in Jessie (-security) does not carry the AppArmor profile:

git diff --stat debian/master..debian/jessie-security -- debian/apparmor/usr.bin.icedove
debian/apparmor/usr.bin.icedove | 286 --------------------------------------------------------------------------------------------------------------------------------------
1 file changed, 286 deletions(-)

(which IMO is good, as introducing stuff that breaks some functionality in a Debian stable release would be risky.)

So, if our patches make their way upstream in time for Stretch, Tails 3.0 will include this AppArmor profile. Yeah!

I'll let you decide if this ticket can be closed, or if there's something else to do here. Personally I'd rather see #11964 dealt with before we ship this profile. (Disclaimer: I've been burnt by the fallout of confining Tor Browser, even though there's been lots of discussions with UX folks about the best way to do it. So maybe I'm just traumatized :)

#3 Updated by u 9 months ago

  • Blocked by Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments added

#4 Updated by u 9 months ago

I agree that we should deal with #11964 first.

I suspect that working on including the profile in Tails Jessie is not really worth to be continued, although I had already started. This is because Tails 3.0 will carry the profile - and I'm unsure if I have the time to dive into this much more before this.

#5 Updated by intrigeri 9 months ago

I suspect that working on including the profile in Tails Jessie is not really worth to be continued, although I had already started. This is because Tails 3.0 will carry the profile - and I'm unsure if I have the time to dive into this much more before this.

ACK.

#6 Updated by intrigeri 8 months ago

  • Blocked by deleted (Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments)

#7 Updated by intrigeri 8 months ago

  • Related to deleted (Bug #10750: Ship an AppArmor profile for Icedove in Tails)

#8 Updated by intrigeri 8 months ago

  • Related to Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments added

#9 Updated by intrigeri 8 months ago

  • Status changed from New to In Progress
  • Target version set to Tails_3.0
  • % Done changed from 0 to 10

That won't be a problem in 3.0 once we ship icedove packages based on the Stretch ones in it, so let's focus on #11964 instead. Still, keeping this ticket open as we do need to ship newer icedove packages in 3.0~betaN soon in order to exercise the AppArmor profiles in the context of real-world Tails usage. We can discuss mid-March who's going to do the corresponding work.

#10 Updated by u 7 months ago

  • Priority changed from Normal to Elevated

#11 Updated by u 7 months ago

  • Assignee changed from u to anonym
  • Feature Branch set to icedove:tails/jessie

In jessie/security, the profile does not exist, but our packages are derived from Jessie/security. So we modified our tails/jessie branch. This still needs to be tested though. Thanks :)))

#12 Updated by intrigeri 7 months ago

I've not looked at the actual code, but I guess it will break some use cases that we currently support. FWIW, in the past I've found it useful to discuss such things with the UX team, to ensure that we're making the right safety/usability trade-off :)

#13 Updated by intrigeri 7 months ago

  • Blocked by Bug #11712: Have Icedove built from Stretch with our patchset applied in Tails 3.0 added

#14 Updated by intrigeri 7 months ago

  • Related to deleted (Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments)

#15 Updated by intrigeri 6 months ago

  • Target version changed from Tails_3.0 to Tails_3.0~rc1

#16 Updated by anonym 5 months ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA
  • Feature Branch changed from icedove:tails/jessie to icedove:tails/stretch tails:feature/11712-thunderbird

#17 Updated by intrigeri 5 months ago

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

Before I review'n'merge this, I'd like to see a summary of what the intent is, i.e. what operations will be accepted/denied (and when denied, what's the user story you have in mind). Thanks in advance!

#18 Updated by intrigeri 5 months ago

  • Assignee changed from anonym to u
  • QA Check changed from Info Needed to Ready for QA

#19 Updated by intrigeri 5 months ago

  • Assignee changed from u to intrigeri

#20 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Ready for QA to Dev Needed

same as #12242

#21 Updated by intrigeri 5 months ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

#22 Updated by intrigeri 5 months ago

intrigeri wrote:

Before I review'n'merge this, I'd like to see a summary of what the intent is, i.e. what operations will be accepted/denied (and when denied, what's the user story you have in mind). Thanks in advance!

I'll try to reverse-engineer this myself from the code and actual behaviour.

#23 Updated by intrigeri 5 months ago

  • Related to Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments added

#24 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to anonym
  • Target version changed from Tails_3.0~rc1 to Tails_3.0
  • QA Check changed from Ready for QA to Dev Needed

Thunderbird proposes me to open an attachments but it's forbidden by AppArmor to do so, it gives me a "Launch Application" dialog where I can pick an application (e.g. /usr/bin/gedit) manually, but it won't run.

Logs until that dialog opens, when trying to open an attached picture:

May 18 14:35:50 amnesia thunderbird[7834]: can't init metadata tree /home/amnesia/.local/share/gvfs-metadata/home: open: Permission denied
May 18 14:35:50 amnesia thunderbird[7834]: can't init metadata tree /home/amnesia/.local/share/gvfs-metadata/home: open: Permission denied
May 18 14:35:50 amnesia audit[7964]: AVC apparmor="DENIED" operation="exec" profile="thunderbird" name="/usr/bin/eog" pid=7964 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
May 18 14:35:50 amnesia thunderbird[7834]: Cannot launch application: Failed to execute child process "eog" (Permission denied)
May 18 14:35:50 amnesia kernel: audit: type=1400 audit(1495118150.416:36): apparmor="DENIED" operation="exec" profile="thunderbird" name="/usr/bin/eog" pid=7964 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
May 18 14:35:50 amnesia audit[7966]: AVC apparmor="DENIED" operation="exec" profile="thunderbird" name="/usr/bin/eog" pid=7966 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
May 18 14:35:50 amnesia kernel: audit: type=1400 audit(1495118150.436:37): apparmor="DENIED" operation="exec" profile="thunderbird" name="/usr/bin/eog" pid=7966 comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
May 18 14:35:50 amnesia thunderbird[7834]: Cannot launch default application: Failed to execute child process "eog" (Permission denied)

So it seems that my understanding of the current situation wrt. opening attachments (#11964) was wrong. Ouch.

It's too late for fixing that in 3.0~rc1 so I'll explain what I feel is missing on #11964 and will merge the branch for #11712 and #12242 with the AppArmor profile disabled. Then I'll let you folks decide on a target version.

The other tests I wanted to do afterwards where about checking where attachments can be saved, both with and without the Thunderbird persistence setting enabled. I'd love to see automated tests for that but I definitely won't block on it.

#25 Updated by intrigeri 5 months ago

  • Related to deleted (Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments)

#26 Updated by intrigeri 5 months ago

  • Blocked by Bug #11964: The Thunderbird AppArmor profile should prevent users from opening attachments added

#27 Updated by u 5 months ago

intrigeri wrote:

Thunderbird proposes me to open an attachments but it's forbidden by AppArmor to do so, it gives me a "Launch Application" dialog where I can pick an application (e.g. /usr/bin/gedit) manually, but it won't run.

Basically, Thunderbird should launch something like gnome-open, which would then in turn pick the right application. However it does not, and instead wants to open several applications directly.

Our previous decision about this was:
  • do not allow opening attachments from Thunderbird in Tails but simply let users save them
  • allow opening attachments from Thunderbird in Debian, because otherwise this is completely unusable (I had prepared a patch for that upstream, which I need to check for merging again, and the profile in Debian was not updated yet either).

#28 Updated by anonym 5 months ago

intrigeri wrote:

Thunderbird proposes me to open an attachments but it's forbidden by AppArmor to do so, it gives me a "Launch Application" dialog where I can pick an application (e.g. /usr/bin/gedit) manually, but it won't run.

Logs until that dialog opens, when trying to open an attached picture:

[...]

So it seems that my understanding of the current situation wrt. opening attachments (#11964) was wrong. Ouch.

Interesting! I only texted with a .txt and that does work, i.e. Gedit starts with the attachement opened. In this case it opens if I just click "Open", and I don't have to select which application to start with; Gedit must be associated already. This seems to be because the usr.bin.thunderbird profile includes abstractions/ubuntu-browsers, which I guess automatically includes abstractions/ubuntu-browsers.d/text-editors, which allows starting gedit.

That's different from e.g. PDFs and PNGs, which opens the "Launch application" prompt where I can provide the application. Everything I try seems to fail there.

So, this explains the misunderstanding!

The other tests I wanted to do afterwards where about checking where attachments can be saved, both with and without the Thunderbird persistence setting enabled.

You can save attachments to anywhere but ~/.gnupg and ~/.ssh. Those are also the only directories you cannot read files from (but you can list the directory contents).

#29 Updated by anonym 5 months ago

  • Type of work changed from Code to Discuss

u wrote:

intrigeri wrote:

Thunderbird proposes me to open an attachments but it's forbidden by AppArmor to do so, it gives me a "Launch Application" dialog where I can pick an application (e.g. /usr/bin/gedit) manually, but it won't run.

Basically, Thunderbird should launch something like gnome-open, which would then in turn pick the right application. However it does not, and instead wants to open several applications directly.

Our previous decision about this was:
  • do not allow opening attachments from Thunderbird in Tails but simply let users save them
  • allow opening attachments from Thunderbird in Debian, because otherwise this is completely unusable (I had prepared a patch for that upstream, which I need to check for merging again, and the profile in Debian was not updated yet either).

Perhaps we should revisit the thinking behind this decision: For the Tor Browser I think our extreme sandboxing makes sense, since web browsers are so exposed. If the browser is compromised, this sandboxing prevents it from starting other applications that could help it extend the compromise. Email clients are less exposed, so it's less likely that the email client itself is compromised. My understanding is that the primary threat via emails are opening malicious attachments => the exposure is in the external applications, not the email client itself.

This makes me think that we are just making things awkward for our users by locking down Thunderbird -- users are still gonna open the saved attachment with the same application. Yup, I feel pretty convinced about this, i.e. that wee should not diverge from the plan we have for Debian. And I think we should make that the case in 3.0 so we don't have to write some docs about the current broken situation.

u, intrigeri: I'd be very interested in your input as soon as possible. I'll keep the ticket assigned to me so I won't lose track of it.

#30 Updated by anonym 5 months ago

BTW, I just saw that the Thunderbird profile has:

  # potentially extremely sensitive files
  audit deny @{HOME}/.gnupg/** mrwkl,
  audit deny @{HOME}/.ssh/** mrwkl,

but we should replace this with:
  # Allow read and write on almost anything in @{HOME}. Lenient, but
  # private-files-strict is in effect.
  #include <abstractions/private-files-strict>
  owner @{HOME}/[^.]*    rw,
  owner @{HOME}/[^.]*/** rw,

like we did for the Totem profile.

#31 Updated by intrigeri 5 months ago

  • Subject changed from AppArmor profile for Icedove missing to AppArmor profile for Thunderbird missing

#32 Updated by intrigeri 5 months ago

Our previous decision about this was:

Right, that's what I remember too :)

  • do not allow opening attachments from Thunderbird in Tails but simply let users save them
  • allow opening attachments from Thunderbird in Debian, because otherwise this is completely unusable

(Nitpicking?:) I'm not quite sure why "otherwise this is completely unusable" doesn't apply to Tails as well.

#33 Updated by intrigeri 5 months ago

  • Type of work changed from Discuss to User interface design

#34 Updated by intrigeri 5 months ago

(Meta: this discussion would be better suited for #11964 but it's too late, so: whatever; we need to make a decision wrt. what we ship in 3.0 here anyway :)

So, regarding 3.0 my understanding is that:

  • the AppArmor profile is not ready to confine Thunderbird while allowing users to open attachments; this affects both Tails and Debian Stretch; Ulrike has something ready locally to be sent upstream, but AFAIK nobody else tested nor reviewed it yet;
  • the UX/doc is not ready to confine Thunderbird without allowing users to open attachments, possibly because our UX folks were not consulted until today.

So as of today, we simply have no option ready for review to confine Thunderbird with AppArmor. Is this assessment of the current situation correct?

Now, let's see what we can do! My primary focus here is 3.0, but I'm open to discussing longer-term plans anyway.

Perhaps we should revisit the thinking behind this decision: For the Tor Browser I think our extreme sandboxing makes sense, since web browsers are so exposed. If the browser is compromised, this sandboxing prevents it from starting other applications that could help it extend the compromise. Email clients are less exposed, so it's less likely that the email client itself is compromised.

Do we have a common understanding that "less exposed" really means two things here:

  • To attack someone via their email client, one needs to target them somewhat (although public mailing lists are a game changer for some categories of people). OTOH a non-targeted, web-based approach is easier to spot as more people are affected.
  • Thunderbird + Torbirdy have a smaller attack surface than Firefox, at least until one enables HTML view of email body (I often have to do that personally). I'm not 100% convinced this is that much of a factor, see below.

?

My understanding is that the primary threat via emails are opening malicious attachments => the exposure is in the external applications, not the email client itself.

My guts feelings says the same, but I'd be more convinced if I saw a quick'n'cheap analysis of the last 10-20 Thunderbird CVEs and how Torbirdy protects at least Thunderbird users who didn't turn HTML email visualization on against these security flaws.

This makes me think that we are just making things awkward for our users by locking down Thunderbird -- users are still gonna open the saved attachment with the same application.

This reasoning totally make sense to me, assuming "the exposure is in the external applications, not the email client itself" is true.

Yup, I feel pretty convinced about this, i.e. that wee should not diverge from the plan we have for Debian. And I think we should make that the case in 3.0 so we don't have to write some docs about the current broken situation.

As the 3.0 RM, I'd be happy to merge a branch that confines Thunderbird without preventing users from opening attachments. I'll require:

  • a list of attachment types that have been tested
  • ensuring that the helper apps used to open attachments are actually confined themselves with their own profile, when applicable (e.g. Evince and Totem)
  • a pull request sent upstream
  • a plan to have these changes in Stretch

We can keep discussing the longer term plan later.

#35 Updated by intrigeri 5 months ago

BTW, I just saw that the Thunderbird profile has:

[...]

but we should replace this with:

[...]

like we did for the Totem profile.

Makes sense to me. IMO this would be acceptable upstream, once tested (in particular it shouldn't break the Icedove → Thunderbird migration, nor access to whatever dotfiles Thunderbird or Enigmail need to read or write).

#36 Updated by sajolida 5 months ago

I'm fine with anonym's proposal.

#37 Updated by intrigeri 5 months ago

intrigeri wrote:

As the 3.0 RM, I'd be happy to merge a branch that confines Thunderbird without preventing users from opening attachments.

Note, however, that during the little time left until 3.0, I'd rather see you folks focus first on regressions currently introduced in 3.0, and second on reproducible builds (aka. the "almost completed, big thing we can better communicate about if it's done in 3.0") rather than on this new feature: I really care about confining Thunderbird but this has been WIP since a year, so at this point postponing a bit more is no big deal, really :)

#38 Updated by anonym 5 months ago

intrigeri wrote:

Our previous decision about this was:

Right, that's what I remember too :)

  • do not allow opening attachments from Thunderbird in Tails but simply let users save them
  • allow opening attachments from Thunderbird in Debian, because otherwise this is completely unusable

(Nitpicking?:) I'm not quite sure why "otherwise this is completely unusable" doesn't apply to Tails as well.

In Tails the UX would be better than in Debian, because only Tails' Thunderbird has patched away the "Open with" option, that won't work. That is one difference between Tails and Debian.

#39 Updated by anonym 5 months ago

intrigeri wrote:

IMO this would be acceptable upstream, once tested (in particular it shouldn't break the Icedove → Thunderbird migration, nor access to whatever dotfiles Thunderbird or Enigmail need to read or write).

Thinking out loud: the wrapper script handling the migration is not confined, so concern about the migration are invalid. But we should indeed let Thunderbird aa-complain a bit to learn which dotfiles/dirs are blocked.

It would be nice if abstractions like private-files-strict had local includes (/etc/apparmor.d/abstractions/local/private-files-strict), so we could deny access to ~/.tor-browser, ~/Persistent/keepassx.kdb and similar sensitive data for applications we ship in Tails, and this would apply for all processes using that abstraction. Right? Or am I missing something?

#40 Updated by anonym 5 months ago

  • Target version changed from Tails_3.0 to Tails_3.2

See #11964#note-30 for the reason of this postponement.

#41 Updated by intrigeri 4 months ago

#42 Updated by intrigeri about 1 month ago

  • Target version changed from Tails_3.2 to Tails_3.4

intrigeri wrote:

  • the AppArmor profile is not ready to confine Thunderbird while allowing users to open attachments; this affects both Tails and Debian Stretch; Ulrike has something ready locally to be sent upstream, but AFAIK nobody else tested nor reviewed it yet;

I've been working on this recently upstream (https://bugs.debian.org/855346, https://bugs.debian.org/874100) but I doubt it will be ready in time for 3.2, and I'd rather not diverge from the Debian profile until we have a better reason to.

#43 Updated by intrigeri 18 days ago

#44 Updated by intrigeri 18 days ago

#45 Updated by intrigeri 18 days ago

  • Target version changed from Tails_3.4 to Tails_3.5

(3.4 will be a bugfix release)

Also available in: Atom PDF