Corresponding ticket: tails#8007 (closed)
Remaining to do
Checked already
Could be improved later
Currently OK
As of 20150604, some of those are OK in
bugfix/8007-AppArmor-hardening
, but not in current stable
.
Unless they're worth special treatment, all changes made as a result
of this audit should land together into Tails 1.5.
- Ux rules don't sanitize
$PATH
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1045986) => they must only be used to run software that does not rely on$PATH
for executing other stuff; in particular, many shell scripts do rely on$PATH
; this should be checked particularly for the profiles we ship that don't come from AppArmor upstream, most notably:- the Tor Browser one: OK, the only
Ux
rule it has is about an ELF executable - Pidgin profile: was vulnerable via
/usr/local/bin/tor-browser
, fixed in Tails 1.4 -
abstractions/tor
: onlyUx
rules are about ELF executables - no other relevant
Ux
rule are present in the profiles we ship
- the Tor Browser one: OK, the only
- use of
sanitized_helper
isn't very safe, especially given it doesn't transition properly with Pix => we don't add occurrences thereof in our own profiles - Tails-specific modifications to profiles:
config/chroot_local-patches/apparmor-adjust-pidgin-profile.diff
config/chroot_local-patches/apparmor-adjust-tor-abstraction.diff
config/chroot_local-patches/apparmor-adjust-tor-profile.diff
config/chroot_local-patches/apparmor-adjust-totem-profile.diff
config/chroot_local-patches/apparmor-adjust-user-tmp-abstraction.diff
- wide-open access to
$HOME
:-
bash
abstraction (included by many profiles) gives read access to$HOME
via@{HOMEDIRS}
, but merely listing its content shouldn't be a problem in practice in Tails: users tend to store their documents on the Desktop, or in persistence. Worst case we'll leak filenames. - no profile we ship includes the
gnupg
abstraction - no profile we ship includes the
user-mail
abstraction, that gives read-write access to mail folders - no profile we ship includes the
user-write
abstraction, that gives read-write access to large parts of$HOME
- the
user-download
abstraction, that's included in the Pidgin profile, gives read-write access non-hidden files at the root of the$HOME
, Desktop and download directories; combined with theprivate-files-strict
abstraction, it is probably as tight as we can do without substantially harming UX -
abstractions/ubuntu-browsers.d/{java,user-files}
give read-write access to$HOME
and its content, but they're not used anywhere
-
- access to webcam:
-
abstractions/video
gives access via/sys/class/video4linux/
so some devices; it's not used in any profile we ship - most webcams appear as
/dev/video0
or similar;rgrep -i video
shows that no profile we ship gives access to such files
-
- access to files via alternate paths specific to Debian Live systems:
-
/live/persistence/TailsData_unlocked/
: we have one automatic test for this inpidgin.feature
; the tested access is denied because that path is not explicitly allowed, rather than because it's explicitly denied, but that's how AppArmor works and that's good enough. - we don't have have any symlink between
/live
and/lib/live
anymore -
/lib/live/mount/rootfs/
and/lib/live/mount/medium/
should be OK: they only contain stuff that's publicly available in our ISO anyway, and DAC still applies. - there's no alternate path to
/live/persistence
-
/lib/live/mount/overlay/
-- until Tails 1.4, we have twotmpfs
mounted there, including an empty one that hides the other's content (but we should not rely on this for security). Fixed on thebugfix/8007-AppArmor-hardening
branch with bc491c9. Note that there's also/live/overlay
(that's a symlink to/lib/live/mount/overlay
, created in 3233da6). Follow-up fixes and corresponding new automatic tests (intorified_browsing.feature
,pidgin.feature
,evince.feature
andtotem.feature
) were added onbugfix/8007-AppArmor-hardening
; the full test suite passes, and the new bits were validated by manual testing. - persistence in read-only mode doesn't bring any additional alternate path
-
private-files
andprivate-files-strict
abstractions do the right thing wrt./lib/live/mount/overlay/home/
, since we add it to @{HOMEDIRS}
-
- wide-open access to
/lib/**
or similar, that might grant access to files via alternate paths -- everything checked, potential issues were:- the
base
andubuntu-helpers
abstraction have things like/lib{,32,64}/** r
: this was patched when introducing aliases (6e48b6d) - the
launchpad-integration
abstraction has things like/** rwlk
and/{,usr/}lib*/{,**/}*.so{,.*} m
; it's harmless since it only gives such rights to an executable we don't ship, and it's included by the Pidgin profile only, which for good measure we disabled with 551d372 onbugfix/8007-AppArmor-hardening
- the
- the kludges needed to make them work with aufs: everything replaced with aliases (and other kludges) in 6e48b6d
- wide-open access to
$HOME
except blacklist -- everything checked, in particular:- Apart of Evince and Totem profiles (discussed elsewhere), only
Pidgin uses one of the
private-files
andprivate-files-strict
abstractions, but it doesn't have any wide-open access rules like Evince or Totem have.
- Apart of Evince and Totem profiles (discussed elsewhere), only
Pidgin uses one of the
-
config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch
- can tell that it's running in Tails: unavoidable in the current state of things
- quite some avenues for fingerprinting of the hardware being used: unavoidable without adding virtualization to the mix
- gives access to
machine-id
: in the current state of things, that tells what exact version of Tails is running; depending on how tails#7100 is addressed, this may become worse; such access was allowed so that the browser can play sound with PulseAudio (commit 371ba40 in our torbrowser-launcher Git repo); if such access is denied, then Tor Browser plays sound directly with Alsa, which makes UX worse... and breaks our automated tests. We'll deal with that as part of tails#7100.