Project

General

Profile

Bug #10750

Ship an AppArmor profile for Icedove in Tails

Added by u over 2 years ago. Updated over 1 year ago.

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

100%

QA Check:
Feature Branch:
451f:tails/feature/11058+apparmor_icedove
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client


Related issues

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

History

#1 Updated by u over 2 years ago

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 u over 2 years ago

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

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 u over 2 years ago

  • 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 u over 2 years ago

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

#5 Updated by u over 2 years ago

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

#6 Updated by u over 2 years ago

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 u over 2 years ago

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

#8 Updated by intrigeri over 2 years ago

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 u over 2 years ago

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 u over 2 years ago

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 u over 2 years ago

  • 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 u over 2 years ago

  • Assignee deleted (u)
  • 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 over 2 years ago

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 u about 2 years ago

  • Subject changed from Consider shipping an AppArmor profile for Icedove in Tails to Ship an AppArmor profile for Icedove in Tails
  • Assignee set to u
  • 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 about 2 years ago

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 u about 2 years ago

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 u about 2 years ago

  • 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 about 2 years ago

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 u about 2 years ago

  • Assignee changed from u 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 about 2 years ago

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 about 2 years ago

  • Assignee changed from intrigeri to u

#23 Updated by u about 2 years ago

  • Assignee changed from u 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 about 2 years ago

  • Assignee changed from intrigeri to u

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 u about 2 years ago

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 u about 2 years ago

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

#27 Updated by u about 2 years ago

  • 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 u almost 2 years ago

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 u almost 2 years ago

  • Type of work changed from Communicate to Code

#31 Updated by u almost 2 years ago

  • Assignee changed from u 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 u almost 2 years ago

  • QA Check set to Ready for QA

#33 Updated by intrigeri almost 2 years ago

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

#34 Updated by intrigeri almost 2 years ago

  • Assignee changed from intrigeri to u
  • 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 #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 #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 u over 1 year ago

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

  • QA Check deleted (Info Needed)

#37 Updated by intrigeri over 1 year ago

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 u over 1 year ago

TODO:

#39 Updated by intrigeri over 1 year ago

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 over 1 year ago

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

#43 Updated by u over 1 year ago

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 over 1 year ago

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 over 1 year ago

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 over 1 year ago

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 u over 1 year ago

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

postponing as 2.7 is already being released.

#48 Updated by u over 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (u)
  • % 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 over 1 year ago

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

#50 Updated by u over 1 year ago

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

#51 Updated by intrigeri about 1 year ago

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

Also available in: Atom PDF