Project

General

Profile

Feature #9337

Notify the user when AppArmor blocks anything

Added by intrigeri over 2 years ago. Updated 16 days ago.

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

0%

QA Check:
Info Needed
Feature Branch:
feature/9337-apparmor-notify
Type of work:
Code
Blueprint:
Easy:
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 over 2 years ago

Install apparmor-notify.

Refs: #9337

Revision fd8bdde0 (diff)
Added by intrigeri over 2 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 over 2 years ago

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

Refs: #9337

Revision 0a325c86 (diff)
Added by intrigeri over 2 years ago

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

Refs: #9337

Revision 0324bc26 (diff)
Added by intrigeri about 2 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 about 2 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 about 2 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 over 2 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 over 2 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 over 2 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 over 2 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 over 2 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 over 2 years ago

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

#7 Updated by intrigeri over 2 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 over 2 years ago

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

#9 Updated by intrigeri over 2 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 over 2 years ago

  • % Done changed from 0 to 10

#11 Updated by intrigeri about 2 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 about 2 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 almost 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 almost 2 years ago

I will spend time on this ticket starting on 12.11.2015.

#15 Updated by sajolida almost 2 years ago

  • Target version changed from 246 to Tails_2.0

#16 Updated by intrigeri almost 2 years ago

  • Related to Feature #9813: Customize AppArmor notifications added

#17 Updated by intrigeri almost 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 1 year 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 over 1 year ago

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

#20 Updated by intrigeri about 1 year ago

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

#21 Updated by intrigeri 11 months ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#22 Updated by intrigeri 10 months 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 7 months ago

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

#24 Updated by intrigeri 5 months 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 4 months 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 4 months 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 20 days ago

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

#28 Updated by mercedes508 16 days ago

  • Assignee changed from mercedes508 to anonym

#29 Updated by intrigeri 16 days 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?

Also available in: Atom PDF