Corresponding ticket: tails#9533 (closed)
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
Short-term
$HOME
except blacklist
Wide-open access to 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 tails-ux@boum.org. 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 breakingkeyringer open
- anywhere below
/media/
(removable storage, and internal storage manually mounted by the user) - anywhere below
/usr/
- XXX: anywhere below
/mnt/
too?
- at the root of
- 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
andprivate-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,
Long-term
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:- this is only done at the AppArmor level. There is WIP to make PulseAudio a trusted helper for microphone access. The "trust-store" is a library (external to AppArmor) that services can use. it can prompt, remember the answer, etc. It's currently limited to mir. It can also be preseeded. jdstrand is not sure if there is a CLI for that, but that could be another option. The broader picture is described in https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement and in the phone-specific bits at https://wiki.ubuntu.com/AccountPrivileges.
- AppArmor support for D-Bus mediation has made it into D-Bus upstream, but the kernel bits have not been upstreamed yet.
- 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
- drop
-
/usr/bin/evince
- drop
bash
abstraction: same as Pidgin - drop
audio
andubuntu-media-players
abstraction: note that PDF can embed videos; do we care? - drop
ubuntu-console-browsers
,ubuntu-console-email
andubuntu-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
- drop
-
/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
- same changes as in