Bug #10750

Ship an AppArmor profile for Icedove in Tails

Added by Anonymous 2015-12-14 03:44:19 . Updated 2016-11-19 10:30:43 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2016-02-05
Due date:
% Done:

100%

Feature Branch:
451f:tails/feature/11058+apparmor_icedove
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:


Subtasks


Related issues

Related to Tails - Bug #11058: Propose a patch against Debian's Icedove package to ship the AppArmor profile there directly Resolved 2016-02-05
Related to Tails - Bug #11964: Discuss if Thunderbird AppArmor profile should prevent users from opening attachments Rejected 2016-11-19

History

#1 Updated by Anonymous 2015-12-14 07:00:08

Comment by intrigeri on tails-icedove@:

Similarly to Firefox, due to the variety of available add-ons, a profile that will work for most people would be so wide open it would be useless, so I don't think it's worth upstreaming it.

However, sharing work with other projects that have similar needs would be great. E.g. I think that Whonix has such profiles already.

#2 Updated by Anonymous 2015-12-14 07:01:39

  • Subject changed from Consider upstreaming Whonix' AppArmor profile for Icedove to Consider using Whonix' AppArmor profile for Icedove in Tails
  • Description updated

Based on intrigeri’s remark, I am updating the ticket title accordingly.

This seems indeed not useful enough to upstream the profile.

#3 Updated by Anonymous 2015-12-14 07:03:44

  • Target version set to Tails_2.2
  • Type of work changed from Code to Test
  • Affected tool set to Email Client

As 2.0 is already frozen, this can be added at most in 2.2.

#4 Updated by Anonymous 2015-12-22 07:03:00

  • Deliverable for set to 268

That’s not part of the deliverable per se but could help increase Icedove’s security.

#5 Updated by Anonymous 2016-01-07 16:30:22

Tested in Debian Sid for now. I could only see DENIED messages for fonts until now.

#6 Updated by Anonymous 2016-01-07 16:43:22

I’ve asked one of our other contributors and aa-experts about the Whonix profile and his comment was that it is so large, it seems not really useful as is. (see rules for mkdir or virtualbox).

I also found a profile by Simon Déziel for Thunderbird: https://github.com/simondeziel/aa-profiles/blob/master/16.04/usr.bin.thunderbird which has some stuff we should deactivate:

 /etc/wildmidi/wildmidi.cfg r,
 #include <abstractions/audio>
 # Pulseaudio
 /usr/bin/pulseaudio Pixr,
 # TODO: investigate
 deny /usr/bin/gconftool-2 x,

As for downloading to $HOME, one shoudl probably define the Download folder only as accessible.

Not sure about this part:

 # so browsing directories works
  / r,
  /**/ r,

I’ve opened an issue for Simon to ask if he tried upstreaming his profile and sent email to Whonix to ask if they think it’s worth remarrying the two profiles.

#7 Updated by Anonymous 2016-01-07 17:26:05

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#8 Updated by intrigeri 2016-01-08 11:33:05

> I also found a profile by Simon Déziel […]

Without having looked at the actual profiles: I vouch for using Simon’s stuff, it’s a pleasure to work with him, and presumably he would be happy to work with us towards having a profile we can both use, and push upstream :)

#9 Updated by Anonymous 2016-01-08 12:06:58

I’ve gotten in touch with him and he asked me to test his profile. Which I’ve been doing since yesterday.
See https://github.com/simondeziel/aa-profiles/issues/3

However, my apparmor version does not accept variables yet, so i had to modify this. Also, his profile assumes using gpg2, which I also had to work around.
But now it works quite fine!

Also, he wants to upstream his profile directly to aa :))))

#10 Updated by Anonymous 2016-01-09 18:17:21

Simon Déziel brought back GPG in the profile.

I still need to test it - and to find out how exactly this could go into Debian, because of the different naming of Thunderbird/Icedove there.

#11 Updated by Anonymous 2016-01-12 12:11:40

  • Subject changed from Consider using Whonix' AppArmor profile for Icedove in Tails to Consider shipping an AppArmor profile for Icedove in Tails

Updating the ticket title according to our research.

#12 Updated by Anonymous 2016-01-12 12:16:12

  • Assignee deleted ()
  • QA Check set to Ready for QA

I’ve tested Simon’s profile (https://github.com/simondeziel/aa-profiles/blob/master/16.04/usr.bin.thunderbird) and would suggest including it in Tails.

Not sure if I should reassing this ticket to somebody or mark it as resolved (the initial question was to test and consider).

#13 Updated by intrigeri 2016-01-13 12:20:39

> Not sure if I should reassing this ticket to somebody or mark it as resolved (the initial question was to test and consider).

My understanding of the discussion wrt. Icedove security fixes vs. Tails release schedule is that we really need to confine Icedove somehow, presumably with AppArmor (I don’t remember any other realistic technical solution being proposed).

So either turn this ticket into one that will track progress on this front, or consider that this ticket was about “considering” only, and then close it and file another one that will track actually fixing the problem at hand; in short: whatever allows you folks to track your work :)

#14 Updated by Anonymous 2016-01-19 18:18:56

  • Subject changed from Consider shipping an AppArmor profile for Icedove in Tails to Ship an AppArmor profile for Icedove in Tails
  • Assignee deleted (None)
  • QA Check deleted (Ready for QA)

Simon has proposed his profile upstream for merging.

TODO:

Get the profile into Debian. Problem will be that this works only with a very recent version of AppArmor, so we either need to find out which aa version is available in Jessie/Jessie-backports or modify the profile for an older version / and possibly also get this older profile merged upstream.

#15 Updated by intrigeri 2016-01-19 18:59:42

> Problem will be that this works only with a very recent version of AppArmor

Are you talking of the version of the userspace, or kernel patches?
What version is needed?

#17 Updated by Anonymous 2016-01-20 11:36:01

intrigeri wrote:
> > Problem will be that this works only with a very recent version of AppArmor
>
> Are you talking of the version of the userspace, or kernel patches?
> What version is needed?

I am not quite sure. All I know is that on Jessie, apparmor does not understand this kind of variables:

@{MOZ_LIBDIR}=/usr/lib/thunderbird

Do you know if the latest version 2.10.x has a remedy for this?

#18 Updated by Anonymous 2016-01-20 11:45:53

  • Type of work changed from Test to Communicate

https://lists.ubuntu.com/archives/apparmor/2016-January/009170.html There’s been a proposal to patch the Ubuntu Thunderbird profile for Debian’s Icedove directly upstream.

#19 Updated by intrigeri 2016-01-20 12:19:17

> All I know is that on Jessie, apparmor does not understand this kind of variables:
>

> @{MOZ_LIBDIR}=/usr/lib/thunderbird
> 

Strange: we use lots of those in /etc/apparmor.d/tunables/, we actually rely a lot on them, and in my experience it works fine. Do you have a simple reproducer for to illustrate this problem?

#20 Updated by Anonymous 2016-01-25 12:23:43

  • Assignee set to intrigeri

intrigeri wrote:
> > All I know is that on Jessie, apparmor does not understand this kind of variables:
> > […]
>
> Strange: we use lots of those in /etc/apparmor.d/tunables/, we actually rely a lot on them, and in my experience it works fine. Do you have a simple reproducer for to illustrate this problem?

Sorry, no simple reproducer, but using this profile (replacing all the occurrences of “thunderbird” by “icedove” and renaming the profile to usr.lib.icedove.icedove), then run aa-enforce:

https://github.com/simondeziel/aa-profiles/blob/master/16.04/usr.bin.thunderbird

#21 Updated by intrigeri 2016-01-25 14:09:39

> Sorry, no simple reproducer, but using this profile (replacing all the occurrences of “thunderbird” by “icedove” and renaming the profile to usr.lib.icedove.icedove), then run aa-enforce:

  • I’m still not sure if it’s the right time for me to look deeper into it. Describing what happens next vs. what you expect should happen might be enough to allow me to help a bit without having to reproduce it myself. Whatever you want :)
  • I assume you’ve apparmor_parser -r’ed it first, right?

#22 Updated by intrigeri 2016-01-26 15:13:12

  • Assignee deleted (intrigeri)

#23 Updated by Anonymous 2016-01-27 12:06:21

  • Assignee set to intrigeri

Aehm, actually no. The good news is that that works.

using https://raw.githubusercontent.com/simondeziel/aa-profiles/master/16.04/usr.bin.thunderbird and replacing all occurrences of thunderbird with icedove, the only error I get is :


# apparmor_parser -r usr.bin.icedove
AppArmor parser error for usr.bin.icedove in usr.bin.icedove at line 251: Could not open 'local/usr.bin.icedove'

#24 Updated by intrigeri 2016-01-27 13:05:26

  • Assignee deleted (intrigeri)

> Assignee changed from u to intrigeri

If anything is expected from me on this ticket, please tell me exactly what it is.

> The good news is that that works.

Cool! :) Thanks for testing again.

#25 Updated by Anonymous 2016-02-05 16:52:42

As discussed over Jabber, until the profile gets merged upstream there are other steps to be taken:

  1. propose a patch to make it work for Thunderbird and the Debian rebranded “Icedove”.
  2. provide a profile in Tails until we have an upstream profile.

#26 Updated by Anonymous 2016-02-10 18:22:21

  • Target version changed from Tails_2.2 to Tails_2.3

#27 Updated by Anonymous 2016-03-10 15:14:46

  • Target version changed from Tails_2.3 to Tails_2.6

Postponing this until we fixed the most important bits of the Icedove in Tails incorporation.

#29 Updated by Anonymous 2016-06-27 13:31:41

I’ve tested the profile from revision 169 of apparmor-profiles (https://bazaar.launchpad.net/~apparmor-dev/apparmor-profiles/master/view/head:/ubuntu/16.10/usr.bin.thunderbird) in Tails 2.4.

It works well, but I detected one problem. When users choose Enigmail’s key creation wizard, they are supposed to create a revocation certificate. But this cert cannot be saved to the location Enigmail wants to use by default. Thus, the supposedly easy procedure of creating a key pair cannot be accomplished. Actually the key pair is created but the user gets an error about the impossibility to create the revocation certificate.

Error:


[16449.351352] audit: type=1400 audit(1467057664.224:36):
apparmor="DENIED" operation="mknod" profile="icedove//gpg2"
name="/home/amnesia/.icedove/profile.default/0xA546D1BB6B894CA3_rev.asc"
pid=6028 comm="gpg2" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Permissions:

drwx------ 10 amnesia amnesia 4096 Jun 27 20:02 profile.default

Solution (to be added to the gpg2 subprofile):

  # for enigmail's wizard revocation certificate creation
  owner @{HOME}/.icedove/profile.default/*_rev.asc rw,

#30 Updated by Anonymous 2016-06-27 13:32:02

  • Type of work changed from Communicate to Code

#31 Updated by Anonymous 2016-06-27 14:27:05

  • Assignee set to intrigeri
  • Feature Branch set to 451f:tails/feature/11058+apparmor_icedove

Tentative implementation at 451f:tails/feature/11058+apparmor_icedove

I did not note where the profile comes from, where should this be documented?
I’m also unsure about the creation of the local/ override.

I’ve submitted the modification ocncerning the revocation cert for comment to the apparmor mailing list.

Tentatively assigning to you for review.

#32 Updated by Anonymous 2016-06-27 14:27:30

  • QA Check set to Ready for QA

#33 Updated by intrigeri 2016-07-13 10:35:48

  • related to Bug #11058: Propose a patch against Debian's Icedove package to ship the AppArmor profile there directly added

#34 Updated by intrigeri 2016-07-13 11:14:11

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

> Tentative implementation at 451f:tails/feature/11058+apparmor_icedove

Thanks! I’ve pushed it to the official repo, so that Jenkins picks it up (even though there’s not much to test until Feature #6304 is done). I’ve also merged the current devel branch into this one. Seems like it was based on master, which is not fit for such work.

> I did not note where the profile comes from, where should this be documented?

The commit message would be a good place to document that.

Given it’s meant to be a temporary solution, I don’t think it’s worth adding that info to the design doc. But then we need a “Replace our custom Icedove AppArmor profile with the one from Debian” ticket, blocked by this one and by Bug #11058, to make sure that this is really temporary :)

> I’m also unsure about the creation of the local/ override.

It looks good to me, but maybe I missed something. What are you unsure about?

> I’ve submitted the modification ocncerning the revocation cert for comment to the apparmor mailing list.

Great!

> Tentatively assigning to you for review.

Let’s rely on the upstream community to review the profile itself. So let’s focus on the integration into Tails.

I don’t want to duplicate work, so what exactly did you test? In a Tails ISO you built, or by modifying a running Tails? With and/or without persistence? Then please reassign to anonym for review, since he’ll be the RM for 2.6.

#35 Updated by Anonymous 2016-07-26 07:53:17

Hi!

intrigeri wrote:
> > Tentative implementation at 451f:tails/feature/11058+apparmor_icedove
>
> Thanks! I’ve pushed it to the official repo, so that Jenkins picks it up (even though there’s not much to test until Feature #6304 is done). I’ve also merged the current devel branch into this one. Seems like it was based on master, which is not fit for such work.

Great!

Oh indeed, I did not think about devel/master.

> > I did not note where the profile comes from, where should this be documented?
> The commit message would be a good place to document that.
> Given it’s meant to be a temporary solution, I don’t think it’s worth adding that info to the design doc. But then we need a “Replace our custom Icedove AppArmor profile with the one from Debian” ticket, blocked by this one and by Bug #11058, to make sure that this is really temporary :)

Ack.

> > I’m also unsure about the creation of the local/ override.
> It looks good to me, but maybe I missed something. What are you unsure about?

I simply was not sure if I did it in the correct manner.

> > I’ve submitted the modification ocncerning the revocation cert for comment to the apparmor mailing list.
>
> Great!

I need to reverify if what Simon Déziel proposed instead works correctly.

> Let’s rely on the upstream community to review the profile itself. So let’s focus on the integration into Tails.

Yes, that’s what I was asking for :)

> I don’t want to duplicate work, so what exactly did you test? In a Tails ISO you built, or by modifying a running Tails? With and/or without persistence? Then please reassign to anonym for review, since he’ll be the RM for 2.6.

I manually installed and loaded the profile in Tails which uses persistence.
Is there a branch which builds an ISO which I could test instead now?

Once I’ll sort out the revocation cert part, I’ll assign this to anonym.

NOTE: I’ve updated my branch with the latest upstream commit to the profile, and this should still be merged.

#36 Updated by Anonymous 2016-07-26 07:53:34

  • QA Check deleted (Info Needed)

#37 Updated by intrigeri 2016-07-26 08:09:37

>> I don’t want to duplicate work, so what exactly did you test? In a Tails ISO you built, or by modifying a running Tails? With and/or without persistence?

> I manually installed and loaded the profile in Tails which uses persistence.

OK. It would be good to test without persistence as well.

> Is there a branch which builds an ISO which I could test instead now?

http://nightly.tails.boum.org/build_Tails_ISO_feature-11058-apparmor-icedove/lastSuccessful/archive/build-artifacts/

I’ve just merged your latest changes and pushed, so make sure you wait enough for the ISO available there to include your latest changes (the filename contains the commit short ID so you can check before downloading). It should land there in about one hour.

#38 Updated by Anonymous 2016-08-18 11:11:13

TODO:

#39 Updated by intrigeri 2016-08-23 03:40:37

Note that this blocks opening attachments with external apps. In Tor Browser we have the same problem so we hide this feature, only giving the user the option to save the file to (the folder where it is allowed to write) on “disk”.

#40 Updated by anonym 2016-09-20 16:54:03

  • Target version changed from Tails_2.6 to Tails_2.7

#41 Updated by Anonymous 2016-10-04 12:46:38

  • Deliverable for changed from 268 to SponsorS_Internal

#42 Updated by Anonymous 2016-10-04 12:46:52

  • Deliverable for deleted (SponsorS_Internal)

#43 Updated by Anonymous 2016-10-04 13:17:26

We still need to document that the apparmor profile prevents people to click on attachments and view them. They can simply download them. That’s an upstream problem and should be fixed there.

#44 Updated by anonym 2016-10-05 08:36:48

u wrote:
> We still need to document that the apparmor profile prevents people to click on attachments and view them. They can simply download them. That’s an upstream problem and should be fixed there.

FWIW a pref to disable “Open with” in the Download dialog recently landed in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1281959). I wonder if this code is shared with Thunderbird, and if so, if it is enough, but I am not very hopeful since the “click on attachments to view them” is quite a different thing. Otherwise, I could have a look at writing a patch………

#45 Updated by anonym 2016-10-05 08:51:09

anonym wrote:
> FWIW a pref to disable “Open with” in the Download dialog recently landed in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1281959). I wonder if this code is shared with Thunderbird, and if so, if it is enough, but I am not very hopeful since the “click on attachments to view them” is quite a different thing.

I just tested this and apparently I remembered wrong how attachments work in Icedove — actually, clicking on the attachment indeed opens the exact same download dialog (with the option to “Open with” and “Download”) that Firefox does.

> Otherwise, I could have a look at writing a patch………

And after reading the ticket I linked to more carefully, it indeed looks like this will land in Thunderbird, so no more patches I presume, yay!

#46 Updated by intrigeri 2016-10-05 09:49:39

> And after reading the ticket I linked to more carefully, it indeed looks like this will land in Thunderbird, so no more patches I presume, yay!

\o/

#47 Updated by Anonymous 2016-11-15 16:39:58

  • Target version changed from Tails_2.7 to Tails_2.9.1

postponing as 2.7 is already being released.

#48 Updated by Anonymous 2016-11-19 10:30:43

  • Status changed from In Progress to Resolved
  • Assignee deleted ()
  • % Done changed from 10 to 100

As we ship our own Icedove based on Debian’s, there already is an AppArmor profile for it in Tails. No need to further create something specific. I’ll close this ticket as resolved.

However, as said, this profile prevents people to click on “Open with” and we need to document this or fix it. I’M creating another ticket for that issue.

#49 Updated by intrigeri 2016-11-19 10:34:40

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

#50 Updated by Anonymous 2016-11-20 16:23:30

  • related to Bug #11973: Confine Thunderbird with AppArmor added

#51 Updated by intrigeri 2017-03-03 07:49:28

  • related to deleted (Bug #11973: Confine Thunderbird with AppArmor)