summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/audit_AppArmor_profiles.mdwn
blob: f35d6ea65dc7ef43d261b7d5223510cacf8c53f8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
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]].