Tails

#1 Updated by Anonymous 2016-11-20 16:23:31

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

#3 Updated by Anonymous 2017-01-17 15:30:15

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

#6 Updated by intrigeri 2017-03-03 07:49:12

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

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

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

#8 Updated by intrigeri 2017-03-03 07:49:30

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

#9 Updated by intrigeri 2017-03-03 07:52:57

• 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 Bug #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 Anonymous 2017-03-17 09:40:39

• Priority changed from Normal to Elevated

#11 Updated by Anonymous 2017-03-19 18:59:20

• Assignee set 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 :)))

#13 Updated by intrigeri 2017-04-02 09:06:05

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

#14 Updated by intrigeri 2017-04-02 09:06:30

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

#15 Updated by intrigeri 2017-04-18 15:25:23

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

#16 Updated by anonym 2017-05-15 15:54:34

• 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 2017-05-16 07:25:04

• 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 2017-05-16 16:43:48

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

#19 Updated by intrigeri 2017-05-16 16:44:13

• Assignee set to intrigeri

#20 Updated by intrigeri 2017-05-16 17:45:28

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

same as Feature #12242

#21 Updated by intrigeri 2017-05-18 09:52:22

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

#23 Updated by intrigeri 2017-05-18 14:53:55

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

#24 Updated by intrigeri 2017-05-18 14:56:00

• 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 (Bug #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 Bug #11964 and will merge the branch for Bug #11712 and Feature #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 2017-05-18 15:03:27

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

#26 Updated by intrigeri 2017-05-18 15:03:37

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

#29 Updated by anonym 2017-05-25 14:55:00

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

#31 Updated by intrigeri 2017-05-25 18:32:55

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

#33 Updated by intrigeri 2017-05-25 18:37:00

• Type of work changed from Discuss to User interface design

#40 Updated by anonym 2017-06-01 16:59:45

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

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

#41 Updated by intrigeri 2017-06-29 10:32:58

• blocks Feature #13234: Core work 2017Q3: Foundations Team added

#42 Updated by intrigeri 2017-09-07 06:39:16

• 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 2017-10-01 09:51:36

• blocks Feature #13245: Core work 2018Q1: Foundations Team added

#44 Updated by intrigeri 2017-10-01 09:51:42

• blocked by deleted (Feature #13234: Core work 2017Q3: Foundations Team)

#45 Updated by intrigeri 2017-10-01 09:52:16

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

(3.4 will be a bugfix release)

#46 Updated by intrigeri 2017-12-10 08:58:27

• 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 (Bug #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 Bug #11964, make that one blocked by Bug #11973 instead of the opposite, and postpone Bug #11964 to 3.8; then Bug #11964 becomes Type of work = User interface design, and Bug #11973 should have Type of work = Code.

#47 Updated by Anonymous 2018-01-19 11:04:49

• Type of work changed from User interface design to Code

#49 Updated by anonym 2018-02-09 13:58:10

• 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 (Bug #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:
>
> # Try to ship this incremental improvement to our users in Tails 3.6 — anonym, can you take care of this?

Yes.

#51 Updated by anonym 2018-02-09 15:21:26

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

#52 Updated by intrigeri 2018-02-10 06:09:56

• 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 2018-02-10 16:09:13

• 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 2018-02-10 16:41:27

• 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 Feature #15298 from being merged.)

#55 Updated by intrigeri 2018-02-14 09:23:17

• 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 2018-02-19 15:34:13

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

#62 Updated by anonym 2018-02-23 15:31:36

• 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 (commit:06548c92425a74f370c7908a4616df8925406187) it ends up in the built’ filesystem it seems. For now I have cherry-picked the “offending” commit (now commit: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.

#64 Updated by intrigeri 2018-02-24 12:11:42

• 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 2018-02-24 13:49:51

• 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 commit: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 Bug #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 2018-02-25 14:10:32

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

#68 Updated by anonym 2018-02-26 10:06:06

• 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 2018-02-26 21:17:34

• 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 Bug #15345.

#70 Updated by bertagaz 2018-02-28 20:17:25

• 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 Bug #15345.

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

#71 Updated by sajolida 2018-03-12 19:34:37

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

#72 Updated by bertagaz 2018-03-14 11:30:21

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

#73 Updated by bertagaz 2018-03-14 11:30:32

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

#74 Updated by bertagaz 2018-03-14 11:30:54

• Status changed from Fix committed to Resolved