summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/harden_AppArmor_profiles.mdwn
blob: 71c01b6528c2d5b6029603803ae5bb999348af55 (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
Corresponding ticket: [[!tails_ticket 9533]]

[[!toc levels=2]]

This is a follow-up on [[blueprint/audit_AppArmor_profiles]], that
tracks improvements we would like to make.

See also the [[contribute/design/application_isolation]] design
documentation, that lists ideas that are at the concept stage.

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

(and thus, to test one last time before submitting the WIP branch for merging)

Beware not to break:

* assistive technologies (accessibility)
* Tails with IUKs installed: test `bugfix/8007-AppArmor-hardening` in
  that context; the changes brought by that branch should not break
  things in that case, but better safe than sorry

Short-term
==========

Wide-open access to `$HOME` except blacklist
--------------------------------------------

Everything was checked in [[blueprint/audit_AppArmor_profiles]],
potential issues and remaining todo items follow.

### whitelist approach

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 the `user-write`
abstraction), and read-only everywhere except for specific
directories? Or is the blacklist used by these profiles tight enough?
=> being discussed on <tails-ux@boum.org>. The current proposal is to
let Evince and Totem read and write any file if, and only if, *all*
the following conditions are met:

- the file has a supported extension;
- the file lives in one of:
  * at the root of `~/`
  * anywhere below the Desktop directory
  * anywhere below `~/Persistent/`, including when accessed directly
    via `/live/persistence/TailsData_unlocked/Persistent/`
  * anywhere below `~/Tor Browser/`
  * at the root of `/tmp/`
  * at the root of `/var/tmp/`
  * at the root of `/run/shm/keyringer.amnesia/`, to avoid breaking
    `keyringer open`
  * anywhere below `/media/` (removable storage, and internal storage
    manually mounted by the user)
  * anywhere below `/usr/`
  * XXX: anywhere below `/mnt/` too?
- unless the file lives in `/media/` or `/usr/`, it must be owned by
  the users who runs the application.

### blacklist approach

If the whitelist approach doesn't work:

- Shall we add stuff to these blacklist? Let's see first if the
  proposed whitelist approach is acceptable => if so, adding to the
  blacklist won't be needed.
- `private-files` and `private-files-strict` are not safe wrt.
  `/live/persistence/TailsData_unlocked/`; we could quickly fix that
  with the following patch:
    
    	--- /etc/apparmor.d/abstractions/private-files-strict.orig	2015-06-04 15:13:25.426658000 +0000
    	+++ /etc/apparmor.d/abstractions/private-files-strict	2015-06-04 15:18:02.402658000 +0000
    	@@ -5,11 +5,11 @@
    	   #include <abstractions/private-files>
    	 
    	   # potentially extremely sensitive files
    	-  audit deny @{HOME}/.gnupg/** mrwkl,
    	-  audit deny @{HOME}/.ssh/** mrwkl,
    	+  audit deny {@{HOME}/.,/live/persistence/TailsData_unlocked/}gnupg/** mrwkl,
    	+  audit deny {@{HOME}/.ssh,/live/persistence/TailsData_unlocked/openssh-client}/** mrwkl,
    	   audit deny @{HOME}/.gnome2_private/** mrwkl,
    	-  audit deny @{HOME}/.gnome2/keyrings/** mrwkl,
    	-  audit deny @{HOME}/.mozilla/** mrwkl,
    	+  audit deny {@{HOME}/.gnome2/keyrings,/live/persistence/TailsData_unlocked/gnome-keyrings}/** mrwkl,
    	+  audit deny @{HOME}/.{mozilla,tor-browser}/** mrwkl,
    	   audit deny @{HOME}/.config/chromium/** mrwkl,
    	   audit deny @{HOME}/.{,mozilla-}thunderbird/** mrwkl,
    	   audit deny @{HOME}/.evolution/** mrwkl,
    

Long-term
=========

<a id="microphone"></a>

Access to microphone
--------------------

In other words: 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?
- The [Oz technical details
  page](https://github.com/subgraph/oz/wiki/Oz-Technical-Details)
  reads: "Access to audio and video recording hardware can also be
  controlled through the Oz policy"; this is implemented with `xpra`'s
  `--microphone`, `--speaker` and `--pulseaudio` options.

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