|
|
|
[[!tag archived]]
|
|
|
|
|
|
|
|
Corresponding ticket: [[!tails_ticket 8007]]
|
|
|
|
|
|
|
|
[[!toc levels=2]]
|
|
|
|
|
|
|
|
Remaining to do
|
|
|
|
===============
|
|
|
|
|
|
|
|
See [[blueprint/harden_AppArmor_profiles]].
|
|
|
|
|
|
|
|
Checked already
|
|
|
|
===============
|
|
|
|
|
|
|
|
Could be improved later
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
See [[blueprint/harden_AppArmor_profiles]].
|
|
|
|
|
|
|
|
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](http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html),
|
|
|
|
especially given it [doesn't transition properly with
|
|
|
|
Pix](https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1042771)
|
|
|
|
=> 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
|
|
|
|
[[!tails_gitweb_commit bc491c9]]. Note that there's also
|
|
|
|
`/live/overlay` (that's a symlink to `/lib/live/mount/overlay`,
|
|
|
|
created in [[!tails_gitweb_commit 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 ([[!tails_gitweb_commit 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 [[!tails_gitweb_commit 551d372]] on
|
|
|
|
`bugfix/8007-AppArmor-hardening`
|
|
|
|
* the kludges needed to make them work with aufs: everything replaced
|
|
|
|
with aliases (and other kludges) in [[!tails_gitweb_commit 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_ticket 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_ticket 7100]]. |
