Project

General

Profile

Feature #9337

Notify the user when AppArmor blocks anything

Added by intrigeri about 3 years ago. Updated 5 months ago.

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

0%

QA Check:
Feature Branch:
feature/9337-apparmor-notify
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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 anythingConfirmedu


Related issues

Related to Tails - Feature #9813: Customize AppArmor notifications Rejected 07/29/2015
Blocked by Tails - Bug #9756: Tighten AppArmor policy, phase 1 Resolved 06/06/2015

Associated revisions

Revision 243f3c83 (diff)
Added by intrigeri about 3 years ago

Install apparmor-notify.

Refs: #9337

Revision fd8bdde0 (diff)
Added by intrigeri about 3 years ago

Install auditd.

Without auditd running, AppArmor logs to syslog, which current aa-notify cannot
parse (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670305#35).

Refs: #9337

Revision 8e22e6a1 (diff)
Added by intrigeri about 3 years ago

Allow the 'amnesia' user to read logs produced by auditd.

Refs: #9337

Revision 0a325c86 (diff)
Added by intrigeri about 3 years ago

Teach aa-notify that members of the auditlog group can read the auditd logs.

Refs: #9337

Revision 0324bc26 (diff)
Added by intrigeri almost 3 years ago

Use auditd's log_group directive instead of manually chgrp/chmod'ing its log file.

Refs: #9337

Revision c42ab7f9 (diff)
Added by intrigeri almost 3 years ago

Don't display daily summary of AppArmor messages when the session starts.

The user generally does not care about whatever AppArmor -related might have
been happening before the GNOME session have started.

Refs: #9337

Revision b31bc16a (diff)
Added by intrigeri almost 3 years ago

Attach /var/log/audit/audit.log to the WhisperBack bug reports.

That's where AppArmor logs now land.

Refs: #9337

History

#1 Updated by u about 3 years ago

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

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

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

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

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

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

#7 Updated by intrigeri about 3 years ago

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

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

#9 Updated by intrigeri about 3 years ago

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

  • % Done changed from 0 to 10

#11 Updated by intrigeri almost 3 years ago

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

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

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

I will spend time on this ticket starting on 12.11.2015.

#15 Updated by sajolida over 2 years ago

  • Target version changed from 246 to Tails_2.0

#16 Updated by intrigeri over 2 years ago

  • Related to Feature #9813: Customize AppArmor notifications added

#17 Updated by intrigeri over 2 years ago

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

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

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

#20 Updated by intrigeri almost 2 years ago

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

#21 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#22 Updated by intrigeri over 1 year ago

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

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

#24 Updated by intrigeri about 1 year ago

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

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

  • 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 10 months ago

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

#28 Updated by mercedes508 10 months ago

  • Assignee changed from mercedes508 to anonym

#29 Updated by intrigeri 10 months ago

  • 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 8 months ago

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

#31 Updated by anonym 6 months ago

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

#32 Updated by mercedes508 6 months ago

  • 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 5 months ago

  • 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 5 months ago

  • 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 5 months ago

  • 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 5 months ago

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 5 months ago

  • Assignee changed from intrigeri to u
  • Target version deleted (Tails_3.6)

(Like the only subtask.)

#38 Updated by emmapeel 5 months ago

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.

Also available in: Atom PDF