audit_AppArmor_profiles

Corresponding ticket: tails#8007 (closed)

Remaining to do
Checked already
- Could be improved later
- Currently OK

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: only Ux rules are about ELF executables
- no other relevant Ux rule are present in the profiles we ship
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 the private-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 in pidgin.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 two tmpfs mounted there, including an empty one that hides the other's content (but we should not rely on this for security). Fixed on the bugfix/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 (in torified_browsing.feature, pidgin.feature, evince.feature and totem.feature) were added on bugfix/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 and private-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 and ubuntu-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 on bugfix/8007-AppArmor-hardening
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 and private-files-strict abstractions, but it doesn't have any wide-open access rules like Evince or Totem have.
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.