summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/audit_AppArmor_profiles.mdwn
blob: 18a941a485ac17d283b0be04edc753f12c964a59 (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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
Corresponding ticket: [[!tails_ticket 8007]]

[[!toc levels=2]]

Things to check
===============

* the kludges needed to make them work with aufs
* access to files via alternate paths specific to Debian Live systems,
  e.g.
  - check `private-files` and `private-files-strict` abstractions, in
    particular wrt. whatever can be accessed via the following paths
  - is there any alternate path to `/live/persistence`?
  - `/lib/live/mount/overlay/` -- until Tails 1.4~rc1, 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]], and then:
    * test that this doesn't break persistence in read-write mode
    * test that this doesn't break persistence in read-only mode
    * test that this doesn't break booting an upgraded Tails with
      more that one SquashFS
    * test how AppArmor confinement behaves wrt. `/live/overlay`
      (that's a symlink to `/lib/live/mount/overlay`, created in
      [[!tails_gitweb_commit 3233da6]]; maybe it's not needed
      anymore?)
    * test result: indeed, AppArmor confinement is now broken wrt.
      `/lib/live/mount/overlay` (at least it allows Tor Browser to access
      stuff in `/lib/live/mount/overlay/home/amnesia/.gnupg/`);
    * add `/lib/live/mount/overlay/home/` to `HOMEDIRS`, so at
      least `$HOME` is OK -- isn't it?
  - recheck all these things with persistence in read-only mode
* wide-open access to `/lib/**` or similar, that might grant access to
  persistent files -- everything checked, potential issues and
  remaining todo items follow:
  - the `base` abstraction (used e.g. by Pidgin and Evince) has things
    like `/lib{,32,64}/** r`
  - the `launchpad-integration` abstraction has
    `/{,usr/}lib*/{,**/}*.so{,.*} m`
  - the `ubuntu-helpers` abstraction has
    `/{,usr/,usr/local/}lib{,32,64}/{,**/}*.so{,.*} m`
* wide-open access to `$HOME` except blacklist -- everything checked,
  potential issues and remaining todo items follow:
  - 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 `user-write`),
    and read-only everywhere except for specific directories? Or is
    the blacklist used by these profiles tight enough?
  - What else uses `private-files` and
    `private-files-strict` abstractions?
  - Shall we add stuff to these blacklist?
* 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
  - `/usr/bin/evince`
    * drop `bash` abstraction: same as Pidgin
    * drop `audio` and `ubuntu-media-players` abstraction:  note that
      PDF can embed videos; do we care?
    * drop `ubuntu-console-browsers`, `ubuntu-console-email` and
      `ubuntu-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
  - `/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
* `config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch`

Things to keep in mind
======================

* Beware not to break assistive technologies (accessibility).

Checked already
===============

Could be improved later
-----------------------

* access to microphone (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](https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1224756).
       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?

Currently OK
------------

* 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.