Project

General

Profile

Bug #11973

Confine Thunderbird with AppArmor

Added by u over 1 year ago. Updated 4 months ago.

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

100%

QA Check:
Pass
Feature Branch:
tails:feature/11973-enable-thunderbird-apparmor-profile icedove:tails/stretch
Type of work:
Code
Blueprint:
Starter:
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

Related to Tails - Bug #15395: Enigmail & AppArmor: Cannot get key from keyserver after finding it Resolved 03/12/2018
Related to Tails - Bug #11964: Discuss if Thunderbird AppArmor profile should prevent users from opening attachments In Progress 11/19/2016
Blocked by Tails - Bug #11712: Have Icedove built from Stretch with our patchset applied in Tails 3.0 Resolved 08/24/2016
Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Resolved 06/29/2017

Associated revisions

Revision e0b8ef9f (diff)
Added by anonym about 1 year 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 about 1 year 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.

Revision 6c678c4a (diff)
Added by anonym 5 months ago

Thunderbird: enable AppArmor profile.

Refs: #11973

Revision 06548c92 (diff)
Added by anonym 5 months ago

Thunderbird: enable AppArmor profile.

Refs: #11973

Revision b104447c (diff)
Added by anonym 5 months ago

Thunderbird: patch AppArmor profile so it compiles in Tails.

Refs: #11973

Revision 71b41069 (diff)
Added by anonym 5 months ago

Thunderbird: fix AppArmor issue during Enigmail key rev-cert generation.

Refs: #11973

Revision 2446bb02 (diff)
Added by anonym 5 months ago

Thunderbird: enable AppArmor profile.

Refs: #11973

Revision ef971b11
Added by bertagaz 5 months ago

Merge remote-tracking branch 'origin/feature/11973-enable-thunderbird-apparmor-profile' into devel

Fix-committed: #11973

History

#1 Updated by u over 1 year ago

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

#2 Updated by intrigeri over 1 year 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 over 1 year ago

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

#4 Updated by u over 1 year 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 over 1 year 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 over 1 year ago

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

#7 Updated by intrigeri over 1 year ago

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

#8 Updated by intrigeri over 1 year ago

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

#9 Updated by intrigeri over 1 year 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 over 1 year ago

  • Priority changed from Normal to Elevated

#11 Updated by u over 1 year 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 over 1 year 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 over 1 year ago

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

#14 Updated by intrigeri over 1 year ago

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

#15 Updated by intrigeri about 1 year ago

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

#16 Updated by anonym about 1 year 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 about 1 year 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 about 1 year ago

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

#19 Updated by intrigeri about 1 year ago

  • Assignee changed from u to intrigeri

#20 Updated by intrigeri about 1 year ago

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

same as #12242

#21 Updated by intrigeri about 1 year ago

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

#22 Updated by intrigeri about 1 year 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 about 1 year ago

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

#24 Updated by intrigeri about 1 year 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 about 1 year ago

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

#26 Updated by intrigeri about 1 year ago

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

#27 Updated by u about 1 year 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 about 1 year 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 about 1 year 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 about 1 year 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 about 1 year ago

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

#32 Updated by intrigeri about 1 year 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 about 1 year ago

  • Type of work changed from Discuss to User interface design

#34 Updated by intrigeri about 1 year 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 about 1 year 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 about 1 year ago

I'm fine with anonym's proposal.

#37 Updated by intrigeri about 1 year 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 about 1 year 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 about 1 year 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 about 1 year 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 about 1 year ago

#42 Updated by intrigeri 10 months ago

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

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 10 months ago

#44 Updated by intrigeri 10 months ago

#45 Updated by intrigeri 10 months ago

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

(3.4 will be a bugfix release)

#46 Updated by intrigeri 7 months ago

  • Subject changed from AppArmor profile for Thunderbird missing to Confine Thunderbird with AppArmor

Vincas Dargis, Simon Deziel and myself greatly improved the AppArmor profile (both upstream and in Debian) in the last couple of months. It is now fairly relaxed e.g. it allows opening attachments. My understanding is that these updates went into Stretch via security uploads. One should double-check all this with a package based on 1:52.5.0-1~deb9u1 (#15033) but there's a reasonable chance it Just Works™ for us i.e. it would add a little bit of security, without harming UX except in rare corner cases.

Potential Tails-specific issues I can think of: aufs weirdness (test both with and without persistent Thunderbird profile), persistent paths, and clicking on links might trigger different behaviour depending on whether Tor Browser is already running (we need to make sure that in both cases, Tor Browser is run under its own profile and not under sanitized_helper). I can help with this if needed, e.g. as a teacher/mentor so anonym learns more about AppArmor.

So I propose we:

  1. Try to ship this incremental improvement to our users in Tails 3.6 — anonym, can you take care of this?
  2. Move the "should we allow opening attachments" discussion to #11964, make that one blocked by #11973 instead of the opposite, and postpone #11964 to 3.8; then #11964 becomes Type of work = User interface design, and #11973 should have Type of work = Code.

#47 Updated by u 6 months ago

  • Type of work changed from User interface design to Code

#48 Updated by u 6 months ago

intrigeri wrote:

Vincas Dargis, Simon Deziel and myself greatly improved the AppArmor profile (both upstream and in Debian) in the last couple of months. It is now fairly relaxed e.g. it allows opening attachments. My understanding is that these updates went into Stretch via security uploads. One should double-check all this with a package based on 1:52.5.0-1~deb9u1 (#15033) but there's a reasonable chance it Just Works™ for us i.e. it would add a little bit of security, without harming UX except in rare corner cases.

Great work! <3

Potential Tails-specific issues I can think of: aufs weirdness (test both with and without persistent Thunderbird profile), persistent paths, and clicking on links might trigger different behaviour depending on whether Tor Browser is already running (we need to make sure that in both cases, Tor Browser is run under its own profile and not under sanitized_helper). I can help with this if needed, e.g. as a teacher/mentor so anonym learns more about AppArmor.

So I propose we:

  1. Try to ship this incremental improvement to our users in Tails 3.6 — anonym, can you take care of this?

This is left to be done on this ticket.

  1. Move the "should we allow opening attachments" discussion to #11964, make that one blocked by #11973 instead of the opposite, and postpone #11964 to 3.8; then #11964 becomes Type of work = User interface design, and #11973 should have Type of work = Code.

I implemented all the suggestions on the corresponding tickets.

#49 Updated by anonym 5 months ago

  • Feature Branch changed from icedove:tails/stretch tails:feature/11712-thunderbird to icedove:tails/stretch tails:feature/15298-thunderbird-52.6.0

intrigeri wrote:

Vincas Dargis, Simon Deziel and myself greatly improved the AppArmor profile (both upstream and in Debian) in the last couple of months. It is now fairly relaxed e.g. it allows opening attachments.

Cool! You rock! _\m/

My understanding is that these updates went into Stretch via security uploads. One should double-check all this with a package based on 1:52.5.0-1~deb9u1 (#15033)

For me this diff is empy:

git diff debian/52.5.2-2_deb9u1.0tails1..debian-upstream/debian/sid -- debian/apparmor/

so we've had these changes since Tails 3.5.

but there's a reasonable chance it Just Works™ for us i.e. it would add a little bit of security, without harming UX except in rare corner cases.

Sadly:

$ rm /etc/apparmor.d/disable/usr.bin.thunderbird
$ apparmor_parser /etc/apparmor.d/usr.bin.thunderbird
profile has merged rule with conflicting x modifiers
ERROR processing regexs for profile thunderbird, failed to load

I'm on it!

Potential Tails-specific issues I can think of: aufs weirdness (test both with and without persistent Thunderbird profile), persistent paths, and clicking on links might trigger different behaviour depending on whether Tor Browser is already running (we need to make sure that in both cases, Tor Browser is run under its own profile and not under sanitized_helper). I can help with this if needed, e.g. as a teacher/mentor so anonym learns more about AppArmor.

Yay, cool! We'll see if this is needed, but I'll look into it.

So I propose we:

  1. Try to ship this incremental improvement to our users in Tails 3.6 — anonym, can you take care of this?

Yes.

#50 Updated by anonym 5 months ago

anonym wrote:

intrigeri wrote:

but there's a reasonable chance it Just Works™ for us i.e. it would add a little bit of security, without harming UX except in rare corner cases.

Sadly:
[...]

I'm on it!

The problematic line is:

/{usr/local/,usr/,}bin/* Cx -> sanitized_helper,

although the expansion to /usr/local/bin/* is ok. For the other two, we indeed get multiple bad merged rules since Cx is incompatible with any other *x flag, which we specify in many other rules for things in /usr/bin/* and /bin/*.

However, the same profile is working for my system running Debian Sid, so I wondered if apparmor 2.12 solves this. Unfortunately, nothing in the changelog seemed to be about this, and actually installing it in Tails didn't help either.

What am I missing?

#51 Updated by anonym 5 months ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Dev Needed to Info Needed

#52 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Info Needed to Dev Needed

anonym wrote:

However, the same profile is working for my system running Debian Sid, so I wondered if apparmor 2.12 solves this. Unfortunately, nothing in the changelog seemed to be about this, and actually installing it in Tails didn't help either.

What am I missing?

Generally this kind of conflicts happening only on Tails are caused by our alias rules, see config/chroot_local-includes/etc/apparmor.d/tunables/alias.d/tails.

#53 Updated by anonym 5 months ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Dev Needed to Info Needed

intrigeri wrote:

anonym wrote:

However, the same profile is working for my system running Debian Sid, so I wondered if apparmor 2.12 solves this. Unfortunately, nothing in the changelog seemed to be about this, and actually installing it in Tails didn't help either.

What am I missing?

Generally this kind of conflicts happening only on Tails are caused by our alias rules, see config/chroot_local-includes/etc/apparmor.d/tunables/alias.d/tails.

Ok. I obviously don't get why by looking at this, but my understanding is that we would have to filter e.g. /usr/bin/* from all binaries we set x for at other points in this profile (or in its includes).

I looked at the AppArmor Core Policy Reference (link via wayback machine, since it has been removed. Any clue where to look for this kind of info from now on?) and found that there is globbing with an exception list: {*^pat1,pat2,…} which would match everything but pat1, pat2, …. Perfect, except maintaining the exclusion list seems like a major pain. Also, a grep -r -F '{^*' /etc/apparmor.d yields nothing, so it doesn't seem to be used by any official profile or include.

So before I start my quest to get an exhaustive exclusion list, am I looking in the wrong direction? I'm starting to think a white-list approach, where we only allow applications we expect to be useful for common attachments:

  /usr/bin/{audacity,eog,evince,gedit,gimp,inkscape,poedit,scribus,totem} Cx -> sanitized_helper,

(I've verified that the above allows starting a .txt with gedit, a .png with eog, and a .pdf with evince.)

However, I'm not sure if that white-list is remotely exhaustive for our users' need among application shipped in Tails, and it clearly will not be enough for applications installed via ASP. The UX is so sucky for applications not in the list (nothing happens, no user visible error) but I still feel inclined to think the above list is good enough.

Alternatively, we set forbid_open_with (just like in Tor Browser) and but the burden of opening the application to the user. At least that will be consistent at all times.

What do you think?

#54 Updated by anonym 5 months ago

  • Feature Branch changed from icedove:tails/stretch tails:feature/15298-thunderbird-52.6.0 to icedove:tails/stretch

(Since we're not done here, I don't want to block #15298 from being merged.)

#55 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to anonym
  • QA Check deleted (Info Needed)

I've managed to make the profile compile this way:

--- /home/amnesia/Downloads/usr.bin.thunderbird    2018-02-14 08:59:10.284000000 +0000
+++ /etc/apparmor.d/usr.bin.thunderbird    2018-02-14 09:07:45.272000000 +0000
@@ -16,7 +16,7 @@
   # TODO: finetune this for required accesses
   #include <abstractions/dbus>
   #include <abstractions/dbus-accessibility>
-  #include <abstractions/dbus-session>
+  # #include <abstractions/dbus-session>
   #include <abstractions/gnome>
   #include <abstractions/ibus>
   #include <abstractions/nameservice>
@@ -24,17 +24,17 @@
   #include <abstractions/p11-kit>
   #include <abstractions/private-files>
   #include <abstractions/ssl_certs>
-  #include <abstractions/ubuntu-browsers>
+  # #include <abstractions/ubuntu-browsers>
   #include <abstractions/ubuntu-browsers.d/java>
   #include <abstractions/ubuntu-helpers>

   # Allow opening attachments
   # TODO: create and use abstractions for opening various file formats
-  /{usr/local/,usr/,}bin/* Cx -> sanitized_helper,
+  /{usr/local/,usr/,}bin/{[^g],g[^p],gp[^g]}* Cx -> sanitized_helper,
   /usr/lib/libreoffice/program/soffice Cxr -> sanitized_helper,

   # For Xubuntu to launch the browser
-  /usr/bin/exo-open ixr,
+  # /usr/bin/exo-open ixr,
   /usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
   /etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
   /etc/xdg/xfce4/helpers.rc r,
@@ -45,7 +45,7 @@
   @{thunderbird_executable} ixr,

   # Pulseaudio
-  /usr/bin/pulseaudio Pixr,
+  # /usr/bin/pulseaudio Pixr,

   owner @{HOME}/.{cache,config}/dconf/user rw,
   owner /run/user/[0-9]*/dconf/user rw,
@@ -138,7 +138,7 @@
   /etc/lsb-release r,
   /etc/ssl/openssl.cnf r,
   /usr/lib/thunderbird/crashreporter ix,
-  /usr/bin/expr ix,
+  # /usr/bin/expr ix,
   /sys/devices/system/cpu/ r,
   /sys/devices/system/cpu/** r,

@@ -194,10 +194,10 @@
   # Ideally these would use a child profile. They are all ELF executables
   # so running with 'Ux', while not ideal, is ok because we will at least
   # benefit from glibc's secure execute.
-  /usr/bin/mkfifo Uxr,  # investigate
-  /{usr/,}bin/ps Uxr,
-  /{usr/,}bin/uname Uxr,
-  /usr/bin/locale Uxr,
+  # /usr/bin/mkfifo Uxr,  # investigate
+  # /{usr/,}bin/ps Uxr,
+  # /{usr/,}bin/uname Uxr,
+  # /usr/bin/locale Uxr,

   /usr/bin/gpg               Cx -> gpg,
   /usr/bin/gpg2              Cx -> gpg,

Thunderbird starts and I can create an IMAP account but I did not test anything else (most notably: opening attachments and URLs, persistence support, GnuPG, etc.). At least the Enigmail setup wizard is broken (can't generate a revokation certificate) but I didn't check if it works on Debian.

Description of my changes:

  • disable two abstractions that are probably useless in our case — but you should check that it does not break accessibility support or opening URLs by clicking on them
  • comment out everything about /usr/bin except the catch-all rule and the rules that transition to the gpg child profile; as a consequence, every binary in there will be executed under sanitized_helper, which makes confinement slightly stricter or slightly more lax depending on the case
  • ensure the catch-all rule does not conflict with the ones about /usr/bin/gpg*; it's ugly and a side-effect is that we'll deny execution of any /usr/bin/gpg* that we don't explicitly cover with a dedicated rule; I'll let you check if there's any such executable in Tails that we should allow running

Some of these changes could be upstreamed to cap our delta and ease maintenance. E.g. if it does not break stuff on Debian, superseding the Ux rules with the catch-all transition to sanitized_helper would simplify the profile and make it slightly safer. The remaining ones (expr, pulseaudio, exo-helper) are more tricky so perhaps they need to be part of our delta.

I think this approach will be easier to maintain (for us) and nicer for our users than the whitelist one: with the whitelist approach, as you said opening attachments with any ASP will be broken, and when our list is lagging behind users will suffer until the next Tails release (assuming they report an actionable bug and we update the list in time).

Instead of commenting out rules, I think a suitable implementation for Tails would instead delete them.

#56 Updated by anonym 5 months ago

  • Feature Branch changed from icedove:tails/stretch to tails:feature/11973-enable-thunderbird-apparmor-profile icedove:tails/stretch

#57 Updated by bertagaz 5 months ago

intrigeri wrote:

I've managed to make the profile compile this way:

I can confirm it fixes apparmor profile loading problem described in #11973#note-49

Thunderbird starts and I can create an IMAP account but I did not test anything else (most notably: opening attachments and URLs, persistence support, GnuPG, etc.). At least the Enigmail setup wizard is broken (can't generate a revokation certificate) but I didn't check if it works on Debian.

I've tested IMAP and SMTP, and sending and opening a OTF file.

I had to add:

--- /tmp/usr.bin.thunderbird    2018-02-19 16:32:26.420000000 +0000
+++ /etc/apparmor.d/usr.bin.thunderbird    2018-02-19 16:36:17.320000000 +0000
@@ -276,6 +276,9 @@
     owner /tmp/nsemail.eml w,
     owner /tmp/nsemail-[0-9]*.eml w,

+    # for revocation certificate generation
+    owner @{HOME}/.{icedove,thunderbird}/profile.default/0x[A-F0-9]*_rev.asc rw,
+
     # for signature verifications
     owner /tmp/data.sig r,
     owner /tmp/data-[0-9]*.sig r,
so that revocation certificate generation works in enigmail wizard (mandatory to finish it the full key generation). Other than that sending and decrypting encrypted emails works.

#58 Updated by intrigeri 5 months ago

I had to add:
[...]
so that revocation certificate generation works in enigmail wizard (mandatory to finish it the full key generation).

This does ring a bell. I think there's a patch floating around upstream to fix exactly that, or a discussion about it on some upstream merge request.

#59 Updated by intrigeri 5 months ago

This does ring a bell. I think there's a patch floating around upstream to fix exactly that, or a discussion about it on some upstream merge request.

I should have been clearer: please check and ensure this is fixed upstream. Let's not start diverging from an upstream profile that I'm maintaining (along with a couple non-Tails people). I now have commit access both to the AppArmor profiles upstream Git repo and to Debian's thunderbird.git so as long as a good pull request is proposed, absolutely nothing prevents us from having fixes in the next upload of Thunderbird to sid + stable security updates.

#60 Updated by bertagaz 5 months ago

I searched a bit in different upstreams I could find (Debian BTS for thunderbird, apparmor-profiles or enigmail, gitlab, github) but could not find such an issue yet.

#61 Updated by bertagaz 5 months ago

bertagaz wrote:

I searched a bit in different upstreams I could find (Debian BTS for thunderbird, apparmor-profiles or enigmail, gitlab, github) but could not find such an issue yet.

In anyway maybe this tiny addition to the icedove apparmor profile can be left over for 3.6 and worked on for 3.7 (uptreaming or fixing upstream and all). We can document in the known issues that for 3.6, OpenPGP key generation has to be done with seahorse before using enigmail, and that may be enough for the moment.

#62 Updated by anonym 5 months ago

  • Assignee changed from anonym to intrigeri
  • QA Check set to Info Needed

intrigeri, it seems not only Tails is adding /etc/apparmor.d/disable/usr.bin.thunderbird, because even with it removed (06548c92425a74f370c7908a4616df8925406187) it ends up in the built' filesystem it seems. For now I have cherry-picked the "offending" commit (now 2446bb0277009670b30c9af33ce11296a7a2abab) to work around this, but I'll look into it.

intrigeri wrote:

I've managed to make the profile compile this way:

Thanks for doing my homework! Just to be clear: I would have happily implemented this approach myself if you thought my other approach was bad and told me so. :)

At least the Enigmail setup wizard is broken (can't generate a revokation certificate) but I didn't check if it works on Debian.

I think that guide is a nice entry point for users to accidentally stumble upon it and actually try it out with a decent UX so breaking it would be said; I'll include bertagaz' patch. Cheers, bert! :)

Description of my changes:

  • disable two abstractions that are probably useless in our case — but you should check that it does not break accessibility support or opening URLs by clicking on them

Both still works!

  • comment out everything about /usr/bin except the catch-all rule and the rules that transition to the gpg child profile; as a consequence, every binary in there will be executed under sanitized_helper, which makes confinement slightly stricter or slightly more lax depending on the case

Fine with me.

  • ensure the catch-all rule does not conflict with the ones about /usr/bin/gpg*; it's ugly and a side-effect is that we'll deny execution of any /usr/bin/gpg* that we don't explicitly cover with a dedicated rule; I'll let you check if there's any such executable in Tails that we should allow running

There's none.

Some of these changes could be upstreamed to cap our delta and ease maintenance. E.g. if it does not break stuff on Debian, superseding the Ux rules with the catch-all transition to sanitized_helper would simplify the profile and make it slightly safer. The remaining ones (expr, pulseaudio, exo-helper) are more tricky so perhaps they need to be part of our delta.

I think this approach will be easier to maintain (for us) and nicer for our users than the whitelist one: with the whitelist approach, as you said opening attachments with any ASP will be broken, and when our list is lagging behind users will suffer until the next Tails release (assuming they report an actionable bug and we update the list in time).

Sounds good to me!

Instead of commenting out rules, I think a suitable implementation for Tails would instead delete them.

Done!

Next, intrigeri, I need AppArmor expertise. I'd like us to also add the following, since it feels ridiculous to allow access to ~/.gnupg and similar:

#include <abstractions/private-files-strict>
owner @{HOME}/[^.]*    rw,
owner @{HOME}/[^.]*/** rw,
owner @{HOME}/.{,mozilla-}thunderbird/** mrwkl,

The last line tries to undo the corresponding line from private-files-strict, but in the end Thunderbird can still not access ~/.thunderbird. What are my options to override other rules?

If this turns out to require more than just a little work, let's postpone it for a next iteration (possibly for 3.7) like bertagaz suggests.

#63 Updated by anonym 5 months ago

anonym wrote:

intrigeri, it seems not only Tails is adding /etc/apparmor.d/disable/usr.bin.thunderbird, because even with it removed (06548c92425a74f370c7908a4616df8925406187) it ends up in the built' filesystem it seems. For now I have cherry-picked the "offending" commit (now 2446bb0277009670b30c9af33ce11296a7a2abab) to work around this, but I'll look into it.

The thunderbird package's debian/thunderbird.postinst script also creates it so we still need 2446bb0277009670b30c9af33ce11296a7a2abab.

#64 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Info Needed to Dev Needed

intrigeri, it seems not only Tails is adding /etc/apparmor.d/disable/usr.bin.thunderbird

Right, sorry I forgot we had to disable the profile by default in Debian.

At least the Enigmail setup wizard is broken (can't generate a revokation certificate) but I didn't check if it works on Debian.

I think that guide is a nice entry point for users to accidentally stumble upon it and actually try it out with a decent UX so breaking it would be said; I'll include bertagaz' patch.

I think the profile.default part is not suitable for upstreaming.

Some of these changes could be upstreamed to cap our delta and ease maintenance. E.g. if it does not break stuff on Debian, superseding the Ux rules with the catch-all transition to sanitized_helper would simplify the profile and make it slightly safer. The remaining ones (expr, pulseaudio, exo-helper) are more tricky so perhaps they need to be part of our delta.

I think this approach will be easier to maintain (for us) and nicer for our users than the whitelist one: with the whitelist approach, as you said opening attachments with any ASP will be broken, and when our list is lagging behind users will suffer until the next Tails release (assuming they report an actionable bug and we update the list in time).

Sounds good to me!

OK, looking forward to your MR upstream then :)

Next, intrigeri, I need AppArmor expertise. I'd like us to also add the following, since it feels ridiculous to allow access to ~/.gnupg and similar:

> #include <abstractions/private-files-strict>
> owner @{HOME}/[^.]*    rw,
> owner @{HOME}/[^.]*/** rw,
> owner @{HOME}/.{,mozilla-}thunderbird/** mrwkl,
> 

The last line tries to undo the corresponding line from private-files-strict, but in the end Thunderbird can still not access ~/.thunderbird. What are my options to override other rules?

This is not gonna work due to a limitation in AppArmor.
See https://gitlab.com/apparmor/apparmor-profiles/merge_requests/6 for a current extensive discussion+WIP on this topic.

#65 Updated by anonym 5 months ago

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

intrigeri wrote:

At least the Enigmail setup wizard is broken (can't generate a revokation certificate) but I didn't check if it works on Debian.

I think that guide is a nice entry point for users to accidentally stumble upon it and actually try it out with a decent UX so breaking it would be said; I'll include bertagaz' patch.

I think the profile.default part is not suitable for upstreaming.

Thanks! Fixed in e403f7ccab73eeff44c890392d2881164c5879dd.

Some of these changes could be upstreamed to cap our delta and ease maintenance. E.g. if it does not break stuff on Debian, superseding the Ux rules with the catch-all transition to sanitized_helper would simplify the profile and make it slightly safer. The remaining ones (expr, pulseaudio, exo-helper) are more tricky so perhaps they need to be part of our delta.

I think this approach will be easier to maintain (for us) and nicer for our users than the whitelist one: with the whitelist approach, as you said opening attachments with any ASP will be broken, and when our list is lagging behind users will suffer until the next Tails release (assuming they report an actionable bug and we update the list in time).

Sounds good to me!

OK, looking forward to your MR upstream then :)

Let's not block on the merge of this branch. I opened #15345 to track this.

Next, intrigeri, I need AppArmor expertise. I'd like us to also add the following, since it feels ridiculous to allow access to ~/.gnupg and similar:

[...]

The last line tries to undo the corresponding line from private-files-strict, but in the end Thunderbird can still not access ~/.thunderbird. What are my options to override other rules?

This is not gonna work due to a limitation in AppArmor.
See https://gitlab.com/apparmor/apparmor-profiles/merge_requests/6 for a current extensive discussion+WIP on this topic.

Got it, thanks!

Also, now that I stopped staring at the diffs of the profile and looked at the full one I noticed the "potentially extremely sensitive files" section which already deal with my chief concerns (~/.{gnupg,ssh}), so I think we're good for Tails.

Let's get this into Tails now! Go, bert, go! :)

#66 Updated by bertagaz 5 months ago

  • Assignee changed from bertagaz to anonym
  • % Done changed from 50 to 60
  • QA Check changed from Ready for QA to Info Needed

anonym wrote:

Let's get this into Tails now! Go, bert, go! :)

Ok, I spent more time testing a fresh ISO of this banch. So far so good, builds and works fine, including enigmail wizard.

I watched closely at apparmor's logs, and noticed this:

Using a different locale than en_US (did not test with this last one though), the logs gets bloated of this lines. They appears for a lot of operations, including while typing each letters of an email address in the To fields when redacting an email (so a bit boring):

apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" \
name="/usr/share/thunderbird/extensions/langpack-fr@thunderbird.mozilla.org.xpi" \
pid=485 comm="gpg2" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

That does not prevent thunderbird to work though. I've not tested by enabling access to this files, not sure it deserves an exception in apparmor.

At the revocation certificate generation, this log appears once but everything goes fine. Maybe it helps to get this certificate in the .gnupg/ directory. At the moment you're displayed a file selection window to input in which folder you want to save it (default to $HOME). Did not try what it looks like when giving access to this directory.

apparmor="DENIED" operation="mkdir" profile="thunderbird//gpg" \
name="/home/amnesia/.gnupg/openpgp-revocs.d/" pid=32592 comm="gpg2" \
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

When sending an email, this line appears one, but the email is sent anyway:

apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" \
name="/home/amnesia/.thunderbird/profile.default/tmp/nsemail.eml" \
pid=497 comm="gpg2" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

I kind of remember that this line appeared when creating the enigmail profile, but I'm not so sure anymore, sorry. It does not prevent anything to work anyway:

apparmor="DENIED" operation="open" profile="thunderbird" \
name="/etc/dconf/profile/user" pid=31895 comm="thunderbird" \
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Automated tests also passes so all in all I think we're good to merge this.

This logs I've seen did not prevent anythink to work. Should we ignore them? Have another ticket about upstreaming our changes and discuss them there? Fix them before merging?

#67 Updated by intrigeri 5 months ago

> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" \
> name="/usr/share/thunderbird/extensions/langpack-fr@thunderbird.mozilla.org.xpi" \
> pid=485 comm="gpg2" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> 

That's because on Linux, any opened FD is inherited by child processes and AppArmor has started mediating that recently. The general solution is to add deny rules to silence the logs.

#68 Updated by anonym 5 months ago

  • QA Check changed from Info Needed to Dev Needed

bertagaz wrote:

anonym wrote:

Let's get this into Tails now! Go, bert, go! :)

Ok, I spent more time testing a fresh ISO of this banch. So far so good, builds and works fine, including enigmail wizard.

Cool!

I watched closely at apparmor's logs, and noticed this:

Using a different locale than en_US (did not test with this last one though), the logs gets bloated of this lines. They appears for a lot of operations, including while typing each letters of an email address in the To fields when redacting an email (so a bit boring):
[...]

That does not prevent thunderbird to work though. I've not tested by enabling access to this files, not sure it deserves an exception in apparmor.

That sounds way too noisy, so I'll at least silence this one for this merge.

#69 Updated by anonym 5 months ago

  • Assignee changed from anonym to bertagaz
  • % Done changed from 60 to 70
  • QA Check changed from Dev Needed to Ready for QA

All issues you reported, bert, are now fixed -- it's pretty much quiet now! Remaining issues:

Feb 26 20:58:56 amnesia kernel: audit: type=1400 audit(1519678736.336:35): apparmor="DENIED" operation="mknod" profile="thunderbird" name="/INBOX.msf" pid=6804 comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Wut? "/INBOX.msf"? For IMAP there is e.g. ~/.thunderbird/profile.default/ImapMail/imap.riseup.net/INBOX.msf .

Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.444:36): apparmor="DENIED" operation="capable" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" capability=19  capname="sys_ptrace" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.444:37): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.444:38): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.444:39): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:40): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:41): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:42): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:43): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:44): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 
Feb 26 21:05:05 amnesia kernel: audit: type=1400 audit(1519679105.448:45): apparmor="DENIED" operation="ptrace" profile="thunderbird//sanitized_helper" pid=7095 comm="ps" peer="unconfined" 

No clue when or why this happened.

Any way, I say this is good enough for Tails 3.6! I post-pone dealing with the above issues to #15345.

#70 Updated by bertagaz 5 months ago

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

anonym wrote:

All issues you reported, bert, are now fixed -- it's pretty much quiet now! Remaining issues:

[...]

Wut? "/INBOX.msf"? For IMAP there is e.g. ~/.thunderbird/profile.default/ImapMail/imap.riseup.net/INBOX.msf .

[...]

No clue when or why this happened.

Any way, I say this is good enough for Tails 3.6! I post-pone dealing with the above issues to #15345.

Agreed, after some more tests, it works fine enough to be released, so it's merged into 3.6.

#71 Updated by sajolida 4 months ago

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

#72 Updated by bertagaz 4 months ago

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

#73 Updated by bertagaz 4 months ago

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

#74 Updated by bertagaz 4 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF