Corresponding ticket: #9533

This is a follow-up on audit AppArmor profiles, that tracks improvements we would like to make.

See also the application isolation design documentation, that lists ideas that are at the concept stage.

Things to keep in mind

(and thus, to test one last time before submitting the WIP branch for merging)

Beware not to break:

  • assistive technologies (accessibility)
  • Tails with IUKs installed: test bugfix/8007-AppArmor-hardening in that context; the changes brought by that branch should not break things in that case, but better safe than sorry


Wide-open access to $HOME except blacklist

Everything was checked in audit AppArmor profiles, potential issues and remaining todo items follow.

whitelist approach

Evince, Totem and their previewers have read-write access to @{HOME}/**: perhaps we can make it a bit tighter, e.g. using a regexp that doesn't include dotfiles (see the user-write abstraction), and read-only everywhere except for specific directories? Or is the blacklist used by these profiles tight enough? => being discussed on The current proposal is to let Evince and Totem read and write any file if, and only if, all the following conditions are met:

  • the file has a supported extension;
  • the file lives in one of:
    • at the root of ~/
    • anywhere below the Desktop directory
    • anywhere below ~/Persistent/, including when accessed directly via /live/persistence/TailsData_unlocked/Persistent/
    • anywhere below ~/Tor Browser/
    • at the root of /tmp/
    • at the root of /var/tmp/
    • at the root of /run/shm/keyringer.amnesia/, to avoid breaking keyringer open
    • anywhere below /media/ (removable storage, and internal storage manually mounted by the user)
    • anywhere below /usr/
    • XXX: anywhere below /mnt/ too?
  • unless the file lives in /media/ or /usr/, it must be owned by the users who runs the application.

blacklist approach

If the whitelist approach doesn't work:

  • Shall we add stuff to these blacklist? Let's see first if the proposed whitelist approach is acceptable => if so, adding to the blacklist won't be needed.
  • private-files and private-files-strict are not safe wrt. /live/persistence/TailsData_unlocked/; we could quickly fix that with the following patch:

      --- /etc/apparmor.d/abstractions/private-files-strict.orig  2015-06-04 15:13:25.426658000 +0000
      +++ /etc/apparmor.d/abstractions/private-files-strict   2015-06-04 15:18:02.402658000 +0000
      @@ -5,11 +5,11 @@
         #include <abstractions/private-files>
         # potentially extremely sensitive files
      -  audit deny @{HOME}/.gnupg/** mrwkl,
      -  audit deny @{HOME}/.ssh/** mrwkl,
      +  audit deny {@{HOME}/.,/live/persistence/TailsData_unlocked/}gnupg/** mrwkl,
      +  audit deny {@{HOME}/.ssh,/live/persistence/TailsData_unlocked/openssh-client}/** mrwkl,
         audit deny @{HOME}/.gnome2_private/** mrwkl,
      -  audit deny @{HOME}/.gnome2/keyrings/** mrwkl,
      -  audit deny @{HOME}/.mozilla/** mrwkl,
      +  audit deny {@{HOME}/.gnome2/keyrings,/live/persistence/TailsData_unlocked/gnome-keyrings}/** mrwkl,
      +  audit deny @{HOME}/.{mozilla,tor-browser}/** mrwkl,
         audit deny @{HOME}/.config/chromium/** mrwkl,
         audit deny @{HOME}/.{,mozilla-}thunderbird/** mrwkl,
         audit deny @{HOME}/.evolution/** mrwkl,


Access to microphone

In other words: can we easily block that while still allowing sound output?

  • abstractions/audio gives full access to PulseAudio, which no doubt gives access to the microphone; we use that abstraction for Totem, Tor Browser, Evince and Pidgin. The Ubuntu phone mediates access to PulseAudio at the D-Bus level. As of 2015-05-04:
  • regarding Alsa:
    • /dev/snd/pcmC[0-9]D[0-9]c raw audio devices seem to be capture, while /dev/snd/pcmC[0-9]D[0-9]p devices seem to be playback devices
    • do /dev/snd/hwC[0-9]D[0-9] give access to the microphone?
    • do /dev/controlC[0-9] give access to the microphone?
    • does /dev/snd/seq give access to the microphone?
    • does /dev/snd/timer give access to the microphone?
  • The Oz technical details page reads: "Access to audio and video recording hardware can also be controlled through the Oz policy"; this is implemented with xpra's --microphone, --speaker and --pulseaudio options.

jvoisin's profile hardening

  • Pidgin
    • drop bash abstraction: has been here since the first version of the profile; that abstraction is not too scary, but... what is it useful for?
    • disable video and audio visualization capabilities: if it doesn't break e.g. accessibility or sound notifications, why not
  • /usr/bin/evince
    • drop bash abstraction: same as Pidgin
    • drop audio and ubuntu-media-players abstraction: note that PDF can embed videos; do we care?
    • drop ubuntu-console-browsers, ubuntu-console-email and ubuntu-gnome-terminal abstractions: I doubt it's useful to anyone in Tails, indeed
    • disallow /usr/bin/yelp: if it breaks displaying Evince help, we don't want that
    • disallow /usr/bin/bug-buddy: Ubuntu-specific, we don't care
    • disallow /usr/bin/exo-open and a bunch of file managers that are not shipped in Tails: not worth maintaining a delta
    • disallow /usr/bin/gedit: a comment in the profile says it's useful "for text attachments", and given it's inheriting the current profile it's not scary enough to be worth potentially breaking things
  • /usr/bin/evince-previewer
    • same changes as in /usr/bin/evince profile, same comments
    • drop ubuntu-browsers abstraction: it doesn't cover Tor Browser anyway, so why not
    • drop ubuntu-email abstraction: do we care about Evince previewer being able to start Claws Mail? What is it useful for?
    • disallow networking access: the Debian kernel doesn't support such rules anyway, so that would be a no-op