Tails

#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.

#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.

#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.

#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 :)

#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?

#16 Updated by Anonymous 2016-01-20 11:29:58

Merge request upstream tracked here: https://code.launchpad.net/~sdeziel/apparmor-profiles/usr.bin.thunderbird-profile/+merge/282383

#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?

#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?

#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?

#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.

#28 Updated by intrigeri 2016-04-13 16:40:34

https://code.launchpad.net/~sdeziel/apparmor-profiles/usr.bin.thunderbird-profile/+merge/282383 was merged upstream.

#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,

#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.

#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:

• Test: set up a PGP identity for any of these accounts (in order to test the AppArmor profile)
• Add latest addition to the profile (see Ximin’s bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833742)

#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”.

#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/