Feature #9337

Notify the user when AppArmor blocks anything

Added by intrigeri 2015-05-04 05:05:28 . Updated 2019-04-07 08:55:06 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2017-06-27
Due date:
% Done:

100%

Feature Branch:
feature/9337-apparmor-notify
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Frontdesk sees a lot of user despair that’s possibly related to AppArmor, and most importantly, to the fact that no notification tells users that AppArmor is blocking things. A first step to mitigate this would be to notify users when AppArmor blocks stuff, so that:

  • users understand a bit better what’s going on, and report more useful bugs, and (for advanced users) workaround the problem locally via /etc/apparmor.d/local/;
  • users and frontdesk can sort apart what’s caused by AppArmor, and what’s not (since apparently, the messages in logs included in Whisperback bug reports are not enough for some unclear reason).

Hopefully this will lead to more actionable tickets being filed :)

The apparmor-notify package could probably be used to achieve this result.

Implementation notes:

  • it may not be in fully-working shape in Wheezy and Jessie, at least without tweaking;
  • it implies to give the amnesia user access to some logs it currently cannot read;
  • it implies to polish a bit our AppArmor policy so that expected denials are silenced.

Subtasks

Feature #13183: Track in Debian: Notify the user when AppArmor blocks anything Rejected

0

Related issues

Related to Tails - Feature #9813: Customize AppArmor notifications Rejected 2015-07-29
Related to Tails - Feature #15678: Improve UX of saving downloaded files from Tor Browser Confirmed 2018-03-27
Blocked by Tails - Bug #9756: Tighten AppArmor policy, phase 1 Resolved 2015-06-06

History

#1 Updated by Anonymous 2015-05-04 05:23:22

> * it implies to polish a bit our AppArmor policy so that expected denials are silenced.

How would that be possible, technically?

#2 Updated by intrigeri 2015-05-04 06:25:40

>> * it implies to polish a bit our AppArmor policy so that expected denials are silenced.

> How would that be possible, technically?

With the deny keyword

#3 Updated by hyas 2015-05-07 08:35:40

I notice in 1.4~rc1 and 1.3.2 that audit denies Vidalia to perform some action (chmod, mkdir, mknod) when you use the network. I guess this need to be fixed before notifications to users are implemented.

#4 Updated by intrigeri 2015-05-07 09:41:41

> I notice in 1.4~rc1 and 1.3.2 that audit denies Vidalia to perform some action (chmod, mkdir, mknod) when you use the network. I guess this need to be fixed before notifications to users are implemented.

Absolutely. If you want to help with this:

  1. boot Tails
  2. set an admin password
  3. find the exact file path+action that’s denied
  4. add corresponding deny rules to /etc/apparmor.d/local/usr.bin.vidalia
  5. run sudo apparmor_parser -r /etc/apparmor.d/usr.bin.vidalia
  6. disconnect from / reconnect to the network (so that Vidalia restarts)
  7. iterate until there’s no more Vidalia-related denial logs
  8. once done, attach your /etc/apparmor.d/local/usr.bin.vidalia here

The AppArmor policy language’s reference is at http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference.
There are plenty of newbie-friendlier tutorials around there.

#5 Updated by hyas 2015-06-01 20:53:23

Please review. Here is a draft for the local profile for vidalia. There is still an audit message with that local profile:

[ 7833.414740] audit: type=1400 audit(1433191245.959:264): apparmor="DENIED" operation="mkdir" profile="/usr/bin/vidalia" name="/lib/live/mount/overlay/home/vidalia/.wh..wh..vidalia.0119/" pid=14648 comm="vidalia" requested_mask="c" denied_mask="c" fsuid=122 ouid=122

# Site-specific additions and overrides for usr.bin.vidalia.
# For more details, please see /etc/apparmor.d/local/README.
/var/cache/fontconfig/ w,
/home/vidalia/.config/ w,
/home/vidalia/.config/* rw,
/home/vidalia/.fontconfig/ w,
/home/vidalia/.fontconfig/* w,
/lib/live/mount/overlay/home/vidalia/.config/* w,
/lib/live/mount/overlay/home/vidalia/.fontconfig/ w,
/lib/live/mount/overlay/home/vidalia/.fontconfig/* w,
/lib/live/mount/overlay/var/cache/fontconfig/ w,

#6 Updated by intrigeri 2015-06-03 08:11:09

Thanks, I’ll take a look and refine as needed during the 1.5 cycle.

#7 Updated by intrigeri 2015-07-18 09:30:05

Apparently, unless we maintain backports of AppArmor 2.9.2+ for Wheezy and Jessie (unlikely), we’ll have to run auditd: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670305#35. But anyway, given feature/jessie doesn’t ship any syslog daemon (the Journal has replaced it), we would have to do that anyway.

#8 Updated by intrigeri 2015-07-19 06:31:44

  • blocked by Bug #9756: Tighten AppArmor policy, phase 1 added

#9 Updated by intrigeri 2015-07-19 06:56:17

  • Status changed from Confirmed to In Progress
  • Feature Branch set to feature/9337-apparmor-notify

Totem triggers noisy notifications. This can be fixed by:

Also:

  • audit.log must be included in WhisperBack reports
  • perhaps we need automated tests that check for unexpected AppArmor denials
  • perhaps we should decrease the delay before notifications (-w 60) since otherwise the “merged” notification points to a place that one can’t see (“thanks” to truncated notifications), and also the user is left for a while without understanding why their action is blocked

#10 Updated by intrigeri 2015-07-19 06:59:47

  • % Done changed from 0 to 10

#11 Updated by intrigeri 2015-07-29 00:31:55

  • Target version changed from Tails_1.5 to Tails_1.7

I won’t have time to complete this before the freeze, sorry. More generally, Tails+AppArmor folks: help is welcome to complete this. Next steps are described in previous note, and the remaining work can be shared between several people.

#12 Updated by intrigeri 2015-10-05 13:27:34

Unlikely to happen in time for 1.7, but let’s keep it on my radar, just in case I’m able to procrastinate some day. Help!

#13 Updated by intrigeri 2015-11-01 04:15:32

  • Target version changed from Tails_1.7 to 246
  • % Done changed from 10 to 50

If I don’t manage do to it for 1.9 I’ll give up. Would be too bad considering that a lot of the work has been done already.

#14 Updated by hyas 2015-11-03 18:37:05

I will spend time on this ticket starting on 12.11.2015.

#15 Updated by sajolida 2015-11-27 04:46:13

  • Target version changed from 246 to Tails_2.0

#16 Updated by intrigeri 2015-11-30 02:17:43

  • related to Feature #9813: Customize AppArmor notifications added

#17 Updated by intrigeri 2015-11-30 02:45:41

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

Won’t be done in time for the 2.0 feature freeze.

#18 Updated by intrigeri 2016-02-12 23:50:32

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

I’m starting to think we should instead work on this in Debian so that it works out-of-the-box in Stretch..

#19 Updated by intrigeri 2016-04-29 14:27:46

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

#20 Updated by intrigeri 2016-08-31 06:08:07

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

#21 Updated by intrigeri 2016-11-25 14:28:22

  • Target version changed from Tails_2.9.1 to Tails 2.10

#22 Updated by intrigeri 2016-12-18 12:41:57

  • Target version changed from Tails 2.10 to Tails_2.12

(I had to take over a bunch of more urgent sysadmin tasks so I’ll postpone this one.)

#23 Updated by intrigeri 2017-03-08 15:15:28

  • Target version changed from Tails_2.12 to Tails_3.2

#24 Updated by intrigeri 2017-06-05 14:03:07

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

intrigeri wrote:
> Frontdesk sees a lot of user despair that’s possibly related to AppArmor

Is this still the case? I’m under the impression that we’ve improved things so the negative impact on UX is smaller.

Meta:

  • I need such input to better focus my efforts on what matters most to our current & future users.
  • As said (mostly to myself) repeatedly above, most of that work must happen in Debian. So u, I was thinking: what about informally adding this to your list of things you could do in case you have leftover time on your “maintain our packages in Debian” at the end of the year? Of course, that’s relevant if, and only if, the user feedback we gather indicates this should be one of our focusses.

#25 Updated by Anonymous 2017-06-27 15:00:31

intrigeri wrote:
> intrigeri wrote:
> > Frontdesk sees a lot of user despair that’s possibly related to AppArmor
>
> Is this still the case? I’m under the impression that we’ve improved things so the negative impact on UX is smaller.

Adding other people from help desk as watchers so they’re aware of this question.

#26 Updated by Anonymous 2017-06-27 15:02:22

> * As said (mostly to myself) repeatedly above, most of that work must happen in Debian. So u, I was thinking: what about informally adding this to your list of things you could do in case you have leftover time on your “maintain our packages in Debian” at the end of the year? Of course, that’s relevant if, and only if, the user feedback we gather indicates this should be one of our focusses.

I’ve added a ticket for myself to track this.

#27 Updated by anonym 2017-09-28 18:29:24

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

#28 Updated by mercedes508 2017-10-02 15:44:52

  • Assignee changed from mercedes508 to anonym

#29 Updated by intrigeri 2017-10-02 17:43:16

  • Assignee changed from anonym to mercedes508

I see no answer to the question I’ve asked help desk 4 months ago, so I don’t understand why you’ve sent this back. Did I miss anything?

#30 Updated by anonym 2017-11-15 11:30:48

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

#31 Updated by anonym 2018-01-23 19:52:30

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

#32 Updated by mercedes508 2018-01-27 13:14:15

  • Assignee changed from mercedes508 to emmapeel

assigning to emma, in order to be more consstent with 2018 evolution of help desk workload.

#33 Updated by emmapeel 2018-02-09 13:09:15

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

We still get users frustrated because they ‘cannot download files with the Browser’.

#34 Updated by intrigeri 2018-02-14 08:24:55

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

emmapeel wrote:
> We still get users frustrated because they ‘cannot download files with the Browser’.

Thanks, that’s useful information. I suspect we can improve on this front without doing everything this ticket is about but it depends on what exactly the users are trying to do, so let me ask: where do they want/try to download files with Tor Browser?

#35 Updated by emmapeel 2018-02-27 09:31:31

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

They try at / and/Pictures, or ~/Downloads

(As a side note, I haven’t seen many users frustrated because they are not able to do that with the Unsafe Browser. Maybe we can have a look at the differences. Although I am not sure if it is because of the documentation or the menus they find when using the Unsafe Broswer.

#36 Updated by intrigeri 2018-02-27 10:56:40

> They try at ~/

OK. We do display that directory (“amnesia”) in the left sidebar of the “Save to…” dialog. I’ve just tried to find a way to hide it but it does not seem doable for Tor Browser only :/
Too bad, my “we can improve on this front without doing everything this ticket is about” hypothesis won’t work, so we’re back to trying to do it in Debian.

> and /Pictures, or/Downloads

AFAICT we don’t provide any way to select these directories as the target for a download in Tor Browser. So, in order to try downloading a file there, the user has to manually type the full path in the “Name:” text entry field. Either some advanced users want to save files there strongly enough to bother typing the full path manually, or we’re not talking about the same thing.

#37 Updated by intrigeri 2018-02-27 10:57:19

  • Assignee deleted (intrigeri)
  • Target version deleted (Tails_3.6)

(Like the only subtask.)

#38 Updated by emmapeel 2018-02-27 11:25:08

intrigeri wrote:
>
> > and /Pictures, or/Downloads
>
> AFAICT we don’t provide any way to select these directories as the target for a download in Tor Browser. So, in order to try downloading a file there, the user has to manually type the full path in the “Name:” text entry field. Either some advanced users want to save files there strongly enough to bother typing the full path manually, or we’re not talking about the same thing.

I think these were users trying to download in the usual directories, after being confronted with a permission error. Maybe if we can catch the user when the ‘save file’ menu appears, then they would not get to look for more directories.

What I mean is: this are the directories where they will usually try to save the files, because they don’t know about Browser confinement; but maybe if they knew they will not try.

#39 Updated by Anonymous 2019-03-12 14:40:22

  • Assignee set to intrigeri

Reassign to intrigeri, as remaining subtask.

#40 Updated by intrigeri 2019-04-07 08:55:06

  • Status changed from In Progress to Rejected
  • Assignee deleted (intrigeri)

I don’t see this happen any time soon. IMO we should focus on Feature #15678 instead.

#41 Updated by intrigeri 2019-04-07 08:55:16

  • related to Feature #15678: Improve UX of saving downloaded files from Tor Browser added