draft.mdwn 34.6 KB
Newer Older
1
2
3
4
---------------------------------------------------------------------

**WARNING!**

5
**This is a preliminary work-in-progress draft, don't believe anything of it (yet).**
6
7
8
9
10

---------------------------------------------------------------------

[[!toc levels=2]]

11
12
13
14
Other design documents:

[[!map pages="contribute/design/*"]]

15
16
**FIXME**

17
- find a way to integrate existing documentation; left to do: [[features]]
18
19
20
- missing:
 * iceweasel locale spoofing or not: balance between ease of use for
   non-English-speaking users and browser fingerprinting
21
22
 * browser fingerprinting: how this is actually implemented in
   T(A)ILS, what compromises are made, and what the actual results are
23
24
25
- have a look to the [Tor design
  document](https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf)
  that might have content we need to put here
26
- parts of the [Live CD Best
27
  Practices](https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/LiveCDBestPractices)
28
29
30
31
  document on the Tor wiki that could be worth merging:
 * the part about default Firefox bookmarks needs to be investigated
 * the part about disabling HTTP keepalive needs to be thought of
 * oh! we don't talk about swap yet
32
33
34
35
36
37
38
39
40
41
42
- be more explicit about the post-mortem forensics issue. There might
  not be much to say but I think that it should at least be mentioned
  in the requirements, part 2:
  * What is required for a PELD to prevent from post-mortem analysis?
  * How do we think this should be provided?
- More generally this whole post-mortem analysis thingie is the real
  difference to put forward while talking to the Tor people; bringing
  their privacy concerns further than just the Internet connection.
  You can be a Tor freak and get the same Tor configuration as T(A)ILS
  on your own system but you won't get the same post-mortem analysis
  protection.
43
44

# 1 Introduction
45
46

In this document we present a specification of a Privacy Enhancing
47
LiveDistro (PELD) as well as an actual implementation of it called The
48
49
(Amnesic) Incognito Live System (in short: *T(A)ILS*).

50
51
52
53
54
55
By writing this document we intent to help third-parties to do
security analyses of any given PELD and specifically of T(A)ILS.
Another of our wishes is to contribute establishing best practices in
the field of PELD design and implementation, and thus raise the
baseline for all similar projects out there.

56
57
58
59
This document is heavily based on preliminary work that was done as
part of [Incognito 2008.1-r1
Documentation](http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html).

T(A)ILS developers's avatar
T(A)ILS developers committed
60
# 2 Privacy Enhancing LiveDistro Specification
61

62
## 2.1 Intent
63

64
### 2.1.1 Privacy on the Internet
65
66
67
68
69
70
71
72
73
74

The Privacy Enhancing LiveDistro (or PELD for short) aims at providing
a software solution presenting the user with the technological means
for using popular Internet technologies while maintaining the privacy
of the user, in particular with respect to anonymity. While there are
different techniques and services providing that functionality, this
specification will assume the usage of [The Tor™
Project](https://www.torproject.org/)'s state-of-the-art anonymizing
overlay network Tor.

75
76
77
78
79
80
81
82
83
### 2.1.2 Working on sensitive documents

The PELD also aims at providing a "safe" environment to work on
sensitive documents:

- No trace must be left on local storage devices unless the user
  explicitly asks for it.
- The usage of encrypted removable storage devices (such as USB
  sticks) should be encouraged.
T(A)ILS developers's avatar
T(A)ILS developers committed
84
85
- No specific user information should be left in the sensitive documents made
  on or published with the PELD (for example EXIF data).
86

87
88
89
90
91
92
93
94
95
**FIXME**: I don't really understand the last requirement. It seems to
me this implies the PELD should modify on-the-fly any file present on
a USB stick, e.g. (but not only) when a user selects it in the web
browser to upload it; I doubt this is actually desirable. Providing
tools to remove metadata from documents would be a welcome bonus but I
am not sure about forcibly doing so. Also, "no specific user
information" seems pretty vague to me, as well as the restriction of
this requirement to "sensitive documents".

96
97
### 2.1.3 Portability

98
99
100
101
The PELD is supposed to be self-contained and portable (literally, not
necessarily with respect to code portability), and thus possible to
run in as many computing environments as possible fot the same single
distribution. In addition, while the PELD's main objective indeed is
102
103
104
105
106
107
to act as a traditional LiveDistro (i.e. a [[!wikipedia Live_CD]] or
[[!wikipedia Live_USB]]) it should also be compatible with popular
virtual machine technologies for users that simply want a sandboxed
environment within their normal operating system.

### 2.1.4 Target user
108
109
110
111
112
113
114
115
116
117
118
119
120

The PELD's target user is the average user in terms of computer
literacy, and who is using a computer of which he or she not
necessarily have full control of. Examples would be a public computer
in a library, coffee shop, university or a residence. The target user
is assumed to not want to do any of the configurations (at least with
respect to security and anonymity) of the various applications and
tools used themselves, either because of insufficient knowledge, lack
of interest or other reasons. The PELD should provide strong anonymity
with no need of advanced configuration whatsoever. It should be made
as difficult as possible for the user to unknowingly compromise
anonymity.

121
122
123
124
### 2.1.5 Summary

In short, the PELD aims at providing privacy on computers and on the
Internet for anyone anywhere.
125

126
## 2.2 Threat model
127
128

The goal of staying anonymous and keeping sensitive information
129
protected stands in direct conflict with the goals of several entities
130
131
"present" on the Internet. The following threat model is meant to
describe the intentions and capabilities of such hypothetical
132
attackers.
133

134
### 2.2.1 The goal of the attacker
135
136
137
138

- **Identify the user's activities on the Internet**: Information such
  as user-agent, locale and (especially) IP address can all be used in
  various degrees to identify the user.
139
- **Eavesdrop on sensitive data**: The Tor network only prevents the
140
141
  data from being traced (according to Tor's threat model) but does not
  protect it from eavesdropping.
142
- **Post-mortem user activity and sensitive data recovery (forensics)**:
143
144
  "Normal" operating systems keep a lot of traces about their users'
  Internet activities (notably browser cache and cookies) on local
T(A)ILS developers's avatar
T(A)ILS developers committed
145
  storage media; similary, working on a sensitive document with a
146
147
148
149
150
151
152
153
154
155
  "normal" operating system is likely to leave traces of this
  document. The adversary may want to recover such information by
  analyzing the equipment that has been used.

### 2.2.2 Capabilities, methods and other means of the attacker

- **Eavesdropping**: It is assumed that the adversary is non-global
  and has full control over the network traffic of some fractions of
  the Internet (e.g. some exit nodes or the Internet connection the
  user is sitting behind).
156
157
158
159
- **Bypass attacks**: It is conceivable for attackers to mount attacks
  which bypass the proxy and DNS setup in the applications which could
  then be used to identify the user, either by injecting data or
  social engineering.
160
- **Exploit software vulnerabilities**: The attacker might be able to
161
162
163
164
165
166
  run arbitrary code by exploiting unpatched vulnerabilities present
  in any of the software packages installed.
- **Application level attacks**: The attacker can utilize certain
  applications' services and features to get identifying information.
  Examples are JavaScript and Java applets in web browsers, CTCP
  queries in IRC clients, etc.
167
168
169
170
171
- **Post-mortem equipment analysis**: The adversary might raid the
  user at any moment and then confiscate and analyse the equipment,
  storage media and memory in particular.
- **Live physical monitoring**: the adversary might be physically
  monitoring the computer while the PELD is running on it.
172

173
## 2.3 Distribution
174
175
176
177
178
179

The PELD should be distributed in a common format that can easily be
used to install the PELD on the selected medium. For instance, if
distributed as an ISO 9660 compatible image file it can be burned to a
CD with almost any CD recording software available.

180
181
182
183
Also, it is recommended to make it possible for end-users to verify
the downloaded PELD support integrity using public key cryptography.

## 2.4 Operational requirements
184
185
186
187
188

This section handles mostly the criteria that the PELD should be
portable and able to run in as many environments as possible. It also
deals with issues such as virus infections and leaving traces.

189
### 2.4.1 Platform
190
191

The binaries should all be executable on the most common computer
192
hardware architecture(s). As of 2011, the x86 computer architecture
193
seems to be the obvious choice as the vast majority of personal
194
195
196
computers in use is compatible with it. Supporting the PowerPC
architecture is a welcome bonus in order to support pre-Intel Apple
computers.
197

198
### 2.4.2 Media
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223

The PELD should be able to boot and run from either CD or a USB drive.
While running the PELD in that mode it should be completely
independent from the host operating system and all other storage media
on the host computer unless the user explicitly tries to access any of
them.

In all circumstances, binaries, dynamic libraries and other executable
code susceptible to virus infections and similar should always be
completely write-protected, even when running from a writeable USB
medium. Such files should not even be modifiable temporarily, which
could be the case even when running from CD if the filesystem is
loaded into memory (e.g. tmpfs).

Configuration files, temporary files, user home directories and
similar files that most likely need to be modifiable during operation
should only be saved temporarily in memory (e.g. by use of something
like tmpfs or unionfs).

It is tempting to utilize the possibility to write back data when
running from USB as that could be used to allow user settings to be
persistent. If this is considered, this feature should be optional and
offer the possibility to use string encryption for the persistent
storage.

224
### 2.4.3 Virtual machines
225
226
227
228
229
230
231
232

As an alternative to running the PELD natively from a CD or USB, it
should also be possible to run from virtual machines. This is useful
in situations where the user might not have the possibility to run the
PELD natively, which often can be the case with public computers.
Additionally, many users seem to prefer this mode of operation, and
that alone is a reason for making sure it works.

233
## 2.5 Kernel requirements
234
235
236
237
238
239

The role of the kernel is mainly to provide support for the features
required elsewhere in this specification. This includes:

- **Good hardware support**: "Good" is a sketchy word in a
  specification. The general idea is to include as much drivers for
240
241
  relevant hardware as possible, in particular for network cards
  (wired and wireless), video card and anything necessary for basic
242
243
  operation.
- **Support for a stateful firewall with packet filtering
244
  capabilities**: It must somehow be able to separate between traffic
245
  for the functionality of the transparent proxying mentioned in the
246
247
  network section to work. Similarly, it must be able to identify and
  drop non-TCP traffic destined to the Internet.
248
249
250
251
252
253
254
255
- **Security features**: With the dangers of exploitable
  vulnerabilities in any code running, attempts to mitigate these on
  the kernel level is a good idea. Executable space protection with
  the NX bit, address space layout randomization and similar
  techniques are all interesting in this respect. Access control in
  the form of Mandatory Access Control, Role-Based Access control and
  so on should also be considered.

256
## 2.6 Network requirements
257
258
259
260
261

In order to prevent accidental leaks of information, proxy bypass
attacks on Tor and similar, the access to the Internet should be
heavily restricted by a firewall:

262
263
- All non-TCP protocols should be dropped as they are not supported by
  the Tor network.
264
- All TCP traffic not explicitly targeting Tor should be redirected to
265
  the transparent proxy (i.e. to the `TransPort` as set in `torrc`).
266
- All DNS lookups should be made through the Tor network (i.e.
267
  redirected to `DNSPort` as set in `torrc`).
268
269
- All IPv6 traffic must be forbidden as it is not supported by the Tor
  network.
270
271

Note that the above is not necessary (or desirable) for local network
272
(RFC1918) addresses; it is recommended to special-case DNS queries though as
273
274
275
some home routers and captive wifi portals reply the public IP
provided by the ISP when a reverse-lookup of their local host name is
attempted (source: [The State of the DNS and Tor Union (also: a DNS UDP
276
- TCP shim)](http://archives.seul.org/or/talk/Jul-2010/msg00007.html)
277
thread on the or-talk mailing-list).
278

279
280
Any exception to these rules must be thoroughly thought of and
properly documented.
281

282
283
284
## 2.7 User interface and applications

### 2.7.1 General user interface
285
286
287

The user should be able to do all relevant things with easy to use
graphical interfaces. As such it should be presented a solid,
288
289
user-friendly desktop environment with all the expected features after
booting: file management, system settings configuration, support
290
applications etc.
291

292
### 2.7.2 Internet applications
293
294
295
296

At minimum, clients for the following Internet activities must be
supported:

297
298
- **Web browsing**: In the case of web browsing we really encourage
  the use of Firefox as the Tor Project itself has an extension,
299
300
301
  Torbutton, specifically designed for mitigating the risks with non-HTTP
  features, such as JavaScript. Efforts should also be made to avoid browser
  fingerprint, so that it won't reveal the use of a PELD.
302
303
- **Emailing**: Support for PGP or S/MIME is highly recommended. Also,
  beware that the EHLO/HELO sent to the SMTP-server will contain the
304
305
306
  host's IP address in many email clients. The `Message-ID` headers and
  HTML/JavaScript email support are other usual leaking spots that
  should be taken care of.
307
- **IRC and Instant messaging**
308
- **SSH**
309

310
Other recommended clients for Internet activities include:
311
312
313
314
315

- **Bittorrent and/or other type(s) of P2P file-sharing**: Note,
  however, that large scale file-sharing activity in general is
  frowned upon in the Tor community as it consumes extreme amounts of
  bandwidth compared to other kinds of services.
316
- **Collaborative text editor** such as [Gobby](http://gobby.0x539.de).
317
318
319
320
321
322
323
324
- **Remote desktop**

Given that these applications will be the user's interface to the
Internet, these should be chosen with care and security in mind, and
also configured in such a way. In general, as little information as
possible should leak about the user, the applications used and the
system settings.

325
326
327
328
329
330
331
332
### 2.7.3 Document production applications

**FIXME**: the PELD intents to allow "Working on sensitive documents"
=> software for non-Internet activities: word processor, bitmap and
vector graphics, DTP, PO editor, sound recording and editing,
printer and scanner support.

### 2.7.4 Tor
333

334
335
Tor should be setup to enable its DNS server (`DNSPort`) and transparent
proxy (`TransPort`, `TransListen`) so the functionality specified in the
336
337
338
339
340
341
342
343
network section is covered. Since Tor really is at the core of the
PELD only stable releases should be considered. Also, while there are
many other interesting configurations to consider in the Tor manual,
none of them that impairs anonymity or security should be set.

A GUI Tor controller application such as Vidalia or TorK is highly
recommended. However, this requires opening the control port in Tor,
and thus some means of authentication will be required
344
(`CookieAuthentication` preferably) to hinder attacks on the Tor
345
346
software.

347
348
349
350
351
352
### 2.7.5 Hardened tool chain and compiling

**FIXME**: change the "compile all software" recommendation into
something like "carefully balance the added security provided by
compiling all software with hardening options vs. cost in developers
time, ease of maintenance and new contributors involvement".
353
354
355
356
357
358
359
360
361

As an addition to the security against exploitable vulnerabilities
provided by the kernel, compiling software with stack smashing
protection, address space layout randomization and similar compiler
security enhancements is recommended. Note that in some circumstances
compiler level stuff is necessary for utilizing the kernel security
features. Because of this it is recommended to compile essentially all
software from sources to take benefit from these security features.

362
### 2.7.6 Cryptographic tools
363
364
365
366
367

Tools for securely signing, verifying, encrypting and decrypting files
and messages should be available. In particular some implementation of
OpenPGP should be included as it in practice is the de-facto standard
when it comes to these things. GUIs for managing keys and performing
368
369
370
371
372
373
374
375
376
377
the relevant cryptographic tasks should be available. The OpenPGP
implementation should be pre-configured to use an encrypted tunnel
when connecting to a keyserver (read: `hkps://`). Also, it should by
default use up-to-date digests, ciphers and key sizes with respect to
the current commonly agreed best practices.

Tools for creating encrypted storage containers are also recommended.

### 2.7.7 "Virtual" input system

378
379
380
As one of the PELD intent is to permit usage of untrusty computers while
preserving anonymity, measures should be taken against hardware that
might prevent it, such as hardware 
381
382
[keyloggers](http://en.wikipedia.org/wiki/Keylogger). Thus a virtual
keyboard (usable with the mouse) should be available.
383

384
385
386
387
388
389
390
391
392
393
394
395
396
397
### 2.7.8 Entropy

Some crucial applications of the PELD, such as the Tor client, make
heavy use of cryptographic techniques and therefore rely on a high
quality proper pseudo-random number generator (PRNG). Initializing
(seeding) a PRNG is tricky in a Live system context as the system
state after boot, if not fully deterministic, is parametrized by far
less variables than in the case of a non-Live system.

Using an auxiliary entropy source such as
[haveged](http://www.irisa.fr/caps/projects/hipsor/) should thus be
considered.

## 2.8 Usability
398
399
400
401
402
403

Security is usually hard to get. Therefore steps need to be taken in
order to make the user more comfortable with the PELD, and also to
educate the user about the specific risks and quirks with respect to
anonymity on the Internet.

404
### 2.8.1 Internationalization
405
406
407
408
409

The user should be able to easily select his of her language of
preference. User applications should be localized to fit this
preference, as should system settings such as keyboard layout.

410
411
412
The PELD documentation, either online or shipped within, should be
easily translatable. Software written specifically for the PELD should
be developed with i18n/l10n-awareness in mind.
413
414

### 2.8.2 Education and user help
415
416
417

The PELD should include an easily read document explaining how to use
it and its software securely. The user should be assumed to only have
418
419
the knowledge of an average computer user, so it will be required to
explain some general security concepts.
420

421
422
Real-world experience demonstrates that the average user quite rarely
thinks about upgrading his or her PELD copy, and is often pretty happy
423
424
425
426
running an obsolete version affected by numerous well-known security
issues. A PELD running copy should therefore notice it is affected by
known security issues and notify the user if a newer release fixes
some.
427

428
429
430
## 2.9 Other considerations

### 2.9.1 Maintainability
431
432
433
434
435
436

The procedure to update the PELD should not be prohibitive to provide
timely software updates to address issues related to security or
anonymity. A scripted, automatic build procedure is greatly preferred
to manually setting up things.

437
### 2.9.2 Sustainability
438

439
PELD development should be a team work rather than a one person work,
440
441
442
443
and the deep knowledge of this work should be shared between the team
members. Thus the development infrastructure should be thought and
deployed in order to share this knowledge.

444
### 2.9.3 Open-source transparency, easing peer review
445
446
447
448
449
450

For the sake of transparency the use of open-source software is
encouraged. Binary blobs should only be used when no good alternatives
exist, which could be the case with certain hardware drivers or driver
firmwares.

451
452
453
454
455
456
457
458
459
460
461
Having third-parties analyze the PELD security is necessary to ensure
it is working as intended. It is thus recommended for the PELD itself
to be open-source. Moreover decisions with non-trivial implications
should be clearly and publicly documented: such information about what
a PELD implementation intents to achieve and how it does so should be
made available to reviewers.

Third-parties should also be enabled to reproduce a PELD
implementation by building it from the released source code and
publicly available information. The process should yield consistent
results.
462

463
### 2.9.4 Easy feedback
464

465
In order to collect bug reports, wanted features and so on, the PELD
466
project should offer easy ways for end-users to provide feedback to the
467
468
developers (email, web forum, bug tracker, shipped-within application,
...). Efforts should be made to offer the most anonymous (or at least
469
pseudonymous) possible way to send this feedback.
470
471
472

# 3 Implementation

473
T(A)ILS is an implementation of the PELD specification above. It is
474
475
licensed under the GNU GPL version 3 or (at your option) any later
version.
476

477
Critical parts of the config (firewall, polipo and Tor config) are
478
based on the ones from the well known and trusted Incognito.
479
480
481
482
483
484

**NOTICE**: This distribution is provided as-is with no warranty of
fitness for a particular purpose, including total anonymity. Anonymity
depends not only on the software but also on the user understanding
the risks involved and how to overcome those risks.

485
## 3.1 Download
486

487
See the [[download section|download]] on [[T(A)ILS's main site|/index]] for download information.
488

489
490
491
The sources are stored in a bunch of [Git](http://git-scm.com/)
repositories. See the [[git page|git]] on the T(A)ILS wiki for
details.
492

493
494
The latest version of this document can be found on the T(A)ILS
website: [[!tails_website contribute/design]].
495

496
## 3.2 Software
497

498
499
500
501
502
The following software is used in T(A)ILS. This list is not complete,
but only contains packages deemed as important for whatever reason.
The full packages list can be found in the [BitTorrent files download
directory](/torrents/files/) (look for files with the `.packages`
extension).
503

504
### 3.2.1 Core software
505
 
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
- [Debian GNU/Linux](http://www.debian.org/): The base operating
  system, provides hardware detection, infrastructure. Please note
  that the Debian distribution does not provide or endorse this
  software distribution.
- [Debian Live](http://live.debian.net/): Toolkit to build Live
  systems based on Debian.
- [Tor](http://www.torproject.org/): Anonymizing overlay network for
  TCP. Our intention is to always use the latest stable version.
- [polipo](http://www.pps.jussieu.fr/%7Ejch/software/polipo/):
  Caching web proxy.
- [macchanger](http://www.alobbs.com/macchanger): Utility for
  viewing/manipulating the MAC address of network interfaces.
- [pdnsd](http://www.phys.uu.nl/%7Erombouts/pdnsd.html): Caching DNS
  proxy. Configured to forward lookups through Tor.

**FIXME**: explain why we don't recompile everything with hardened
tool chain. Be accurate about the present/missing kernel security
features.

### 3.2.2 Virtual keyboard

- [onBoard](https://launchpad.net/onboard) virtual keyboard as a
  countermeasure against hardware keyloggers.

### 3.2.3 Other applications

**FIXME**: insert an excerpt here (mainly software that is required or
recommended by the above specification)

535
- [cryptsetup](http://code.google.com/p/cryptsetup/) ensures storage
536
  encryption using [LUKS](http://en.wikipedia.org/wiki/LUKS).
537
538
539
- [gnupg](http://gnupg.org) complete and free implementation of the
  OpenPGP standard.
- [Torbutton](https://www.torproject.org/torbutton) offers all kind of
540
  protection against non-HTML anonymity attacks.
541
542
543
544
- [haveged](http://freshmeat.net/projects/haveged) feeds /dev/random
  using HArdware Volatile Entropy Gathering and Expansion algorithm.
- [Vidalia](https://www.torproject.org/projects/vidalia.html.en) is used
  to control Tor's behavior.
545
546
- [secure-delete](http://www.thc.org) a tool to securely wipe data from files,
  swap or memory.
547

548
549
550
See [[features]] for a partial list of bundled software.

## 3.3 Internationalization
551
552
553

The following locales are installed. If you'd like to see another
locale, please let us know.
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571

- ar (Arabic)
- ar_EG.UTF-8 (Egyptian Arabic)
- de, de_DE.UTF-8 (German)
- es, es_ES.UTF-8 (Castellano)
- en_US, en_US.UTF-8 (American English)
- fr, fr_FR.UTF-8 (French)
- it, it_IT.UTF-8 (Italian)
- pt, pt_PT.UTF-8 (Portuguese)
- ru, ru_RU.UTF-8 (Russian)
- zh, zh_CN.UTF-8 (Chinese)

The chosen locale's files are compiled at boot time.

See `config/amnesia` for the selected languages. See
`config/chroot_local-preseed/localepurge` and grep the source for
`AMNESIA_SUPPORTED_LANGUAGES` for how this configuration is applied.

572
573
574
575
576
577
578
579
580
581
582
## 3.4 Notification of security issues and new T(A)ILS release

Shipped in T(A)ILS is a script that checked at each desktop start if
security issues or new T(A)ILS released are published on the website. If
some are found, a notification is printed on the desktop. This
application is internationalized.

See [[!tails_gitweb
chroot_local-includes/usr/local/bin/tails-security-check]]

## 3.5 Configuration
583
584

In this section we briefly present the setup of several key software
585
packages and system settings of T(A)ILS with respect to security and
586
587
588
anonymity. There are of course other minor tweaks here and there, but
those are mainly for usability issues and similar.

589
### 3.5.1 The Tor™ software
590
591
592
593
594
595
596
597
598

The Tor software is currently configured as a client only. The client
listens on SOCKS port 9050 with a control port 9051 (using cookie
authentication), as a transparent proxy on port 9040 and as a DNS
server on port 8853. Only connections from localhost are accepted. It
can be argued that running a server would increase your anonymity for
a number for reasons but we still feel that most users probably would
not want this due to the added consumption of bandwidth.
 
599
- [[!tails_gitweb chroot_local-includes/etc/tor/torrc]]
600

601
### 3.5.3 DNS
602

603
[[!inline pages="contribute/design/Tor_enforcement/DNS" raw=yes]]
604

605
### 3.5.4 HTTP Proxy
606

607
[[!inline pages="contribute/design/Tor_enforcement/Proxy" raw=yes]]
608

609
### 3.5.5 SOCKS libraries
610

611
612
613
614
tsocks and torify are installed. Note that it is unnecessary with the
Linux network filter (see below) and the local DNS server to torify
applications. This is done at a lower level. These tools are solely
here due to dependencies and configured for completeness.
615

616
- [[!tails_gitweb config/chroot_local-includes/etc/tor/tor-tsocks.conf]]
617

618
### 3.5.6 Network Filter
619

620
[[!inline pages="contribute/design/Tor_enforcement/Network_filter" raw=yes]]
621

622
### 3.5.7 Random MAC Address
623

624
625
**FIXME**: this is not implemented yet. See the related [[design
document|design/MAC_address]] and [[todo item|todo/macchanger]].
626

627
### 3.5.8 Iceweasel
628
629
630
631

(Note: Iceweasel is the name of the web browser, based on Mozilla
Firefox, that is shipped by Debian and thus by T(A)ILS.)

T(A)ILS developers's avatar
TODO++  
T(A)ILS developers committed
632
633
634
635
636
**FIXME**: the only history-related setting I can find in our
Iceweasel config is:

    pref/iceweasel.js:pref("browser.history_expire_days", 0);

T(A)ILS developers's avatar
T(A)ILS developers committed
637
638
639
> Does this really mean history disabled? If it does, I wonder if we
> really need/want this. Torbutton also has history-related settings,
> let's check if the defaults are sane for our usecase.
T(A)ILS developers's avatar
TODO++  
T(A)ILS developers committed
640

641
Iceweasel uses Torbutton in order to prevent attacks using JavaScript,
642
643
644
645
646
plugins and other non-HTTP features like web bugs. It is configured to
always be enabled on Iceweasel start and uses polipo as HTTP(s) proxy
and Tor as SOCKS proxy. SOCKS is configured to perform name resolution
through the proxy. Iceweasel is also configured to not cache to disk
(mainly to reduce memory usage for CD users as disk writes will be
647
stored there), history is disabled (just in case) and many other things. It is also setup
T(A)ILS developers's avatar
T(A)ILS developers committed
648
649
not to automatically check for updates of its installed extensions.
Java support is disabled.
650
651
652

Iceweasel is shipped with some extensions to help users into managing
their browsing experience. The
653
[cslite](https://addons.mozilla.org/fr/firefox/addon/5207/)
654
655
656
657
658
659
extension blocks by default all cookies and provides a button for the
user to accept cookies only on websites where the user needs it. This
prevents the known leak of browsing informations cookies can lead to.
The [Adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865/)
extension prevent users from leaving traces of their web browsing by
removing all ads. The [firegpg](http://getfiregpg.org/) plugin allows
660
users to use GnuPG inside websites like webmails.
661

T(A)ILS developers's avatar
T(A)ILS developers committed
662
663
664
665
**FIXME**: any mention of foxyproxy was removed in 813eea6e. While not
shipped in a stable release yet, it is planned for the next one and
installed in the devel branch. IMHO we should mention this.

666
667
The Iceweasel config is pretty heavily commented, so any other relevant
settings may be investigated by looking in it.
668

669
- [[!tails_gitweb config/chroot_local-includes/etc/iceweasel/]]
670

671
### 3.5.9 Claws Mail
672

673
674
**FIXME: adapt and rewrite, using [[the audit draft|todo/applications_audit/claws_mail]]**

675
676
Claws Mail generates `Message-ID` headers using the hostname part
of the sender's email address, which is ok.
677

678
679
It also always says `EHLO localhost` to the SMTP server instead of
disclosing the real IP address and hostname.
680

681
682
Furthermore, the accounts that a user will create are pre-configured
to not use HTML as that otherwise may break PGP usage.
683

684
685
- [[!tails_gitweb config/chroot_local-includes/etc/skel/.claws-mail/]] is copied to
  the user's `$HOME` at boot time
686

687
### 3.5.11 Pidgin
688

689
690
691
692
693
Pidgin is configured to not log anything as well as not to reveal too
much of user activity by disabling online/away reporting. MSN protocol
support is disabled, to avoid the usage of such a privacy flawed and
buggy plugin. The Off-the-record plugin is enabled to help one to one
conversations being as private and unrecordable as possible. A script
694
generates at each boot a random nick to be used on the preconfigured IRC
695
servers.
696

T(A)ILS developers's avatar
T(A)ILS developers committed
697
698
699
**FIXME**: document how T(A)ILS builds the "random" nickname at boot
time, then close [[todo/Pidgin (documentation)]].

700
701
702
703
704
705
### 3.5.12 Host system swap

**FIXME**: explain T(A)ILS does its best not to use any swap partition
that could be found at runtime:

- not using live-boot's swapon option
T(A)ILS developers's avatar
T(A)ILS developers committed
706
707
- [[!tails_gitweb config/chroot_local-hooks/03-noswap]]
- [[!tails_gitweb config/chroot_local-hooks/05-disable_swapon]]
708

709
### 3.5.13 Host system RAM
710

711
**FIXME: mention this is currently sometimes buggy and not to be relied on (yet)**
712
713
714
715
716
717
718
719
720
721

When shutting down the system RAM is securely wiped. RAM can actually
be read after the machine shuts off with the right equipment. The
software doing this is smem, part of the
[secure-delete](http://www.thc.org/) package. This process can take a
while. If you are booting from a CD it should eject, and if you are
booting from a USB drive you can remove the drive once prompted. In
either case you can leave the computer and let it finish on its own,
or simply turn it off if you are not worried about this attack.

722
- [[!tails_live-boot_gitweb debian/live-boot.init]]
723

724
725
726
727
728
729
730
731
732
733
734
735
736
737
### 3.5.14 Host system disks and partitions

**FIXME**: some LiveDistros read the disks and possibly mount the
available partitions automatically. T(A)ILS does not do so for fixed
disks.

Hints to the one who will write this part:

- grep nopersistent config/amnesia
- probably a few GConf settings in
  config/chroot_local-includes/usr/share/amnesia/gconf/
- udev / GNOME / udisks: removable vs. fixed

### 3.5.15 Passwords
738

739
740
741
There are two users that are intended to be used for logins, `amnesia`
and `root`. Both have `amnesia` set as a password, and the `amnesia`
user is allowed to gain super user privileges, without providing a
742
743
744
745
746
747
748
749
750
751
752
753
password, using `sudo`.

The user will remove the CD/USB when done and there should be no
services allowing logins from the network, but still: we are aware of
the security risks involved by password-less sudo and are [[working on
it|todo/better_root_access_control]].

As a first step the next major T(A)ILS release will stop grant `sudo`
privileges to the `amnesia` user; a root console will be available for
two minutes after boot: this leaves the user 2 minutes to set a root
password. Unless this is done before this delay has expired, the root
console will be disabled, and no root access will be possible anymore.
754

755
## 3.6 Running T(A)ILS in virtual machines
756

757
T(A)ILS may of course be run in virtual machines. Due to the
758
759
popularity of [VMWare](http://www.vmware.com/) we include
[open-vm-tools](http://open-vm-tools.sourceforge.net/) (an open-source
760
alternative to VMware tools) as well as special video drivers
761
762
763
for an improved user experience in that environment. Due to the
closed-source nature of VMWare we try to encourage users of open VMs,
like [VirtualBox](http://virtualbox.org/) and
764
[QEMU](http://www.qemu.org/), by making sure that
765
these also work. In the case of VirtualBox both video and input
766
drivers are included, as well as the guest utilities.
767
768

Security concerns for all VMs are a keyloggers, viruses and other
769
770
malware in the host OS which a guest OS like T(A)ILS cannot defend
against. T(A)ILS therefore tries to detect whether it is run inside a
771
VM and [[warns the user|design/virtualization_support]] if it is.
772

773
## 3.7 Running T(A)ILS inside a Windows session
774

775
776
777
**FIXME**: not implemented yet, see the
[[todo/virtualization_support]] TODO item. Let's implement this
instead of changing the following paragraph :)
778
779
780
781
782
783

[QEMU](http://www.qemu.org/) for Microsoft Window ships with T(A)ILS
and is used to run the CD/USB in a virtual machine whenever native
boot is impossible or not desirable. Note that this will work for
Windows 2000/XP or greater only.

784
## 3.8 Build process and maintenance
785
786
787
788
789
790
791

The Debian Live release build tool is used to build T(A)ILS. This tool
is designed automate the build process of the target distribution,
which also make them easy to maintain.

For detailed instructions on how to build and modify T(A)ILS, see
[[build]] and [[contribute]] on the wiki.
792
793
794
795
796
797

The following applications are kept up to date as soon as possible.

- Tor (stable releases only) 
- Vidalia 

798
799
800
Remaining applications, including the base system, will be updated
using Debian standard upgrade process, and generally based on the
latest Debian stable release so there are not many problems.
801

802
## 3.9 Hardware support
803
804
805
806
807
808
809
810

T(A)ILS ships with the latest kernel from [Debian
Backports](http://backports.debian.org) as a compromise between
stability and recent hardware support.

The x86 hardware architecture is the main supported one but work is
ongoing to additionally support the PowerPC architecture.

811
## 3.10 Caveats
812

813
814
815
816
817
818
819
820
821
822
823
824
825
826
UDP and IPv6 are a problem. The Tor network does not support any of
those yet. Outgoing UDP and IPv6 packets are dropped altogether by
netfilter for this reason.

Also, an easy (read: not command-line based) way to [[install and
upgrade T(A)ILS on USB sticks|todo/usb_install_and_upgrade]] is
needed.

Some optional bits of [[todo/persistence]] would be welcome and help
spreading strong public key cryptography and authentication amongst
T(A)ILS users (OpenPGP, [[todo/Monkeysphere]]).

See the [[contribute/roadmap]] for more information about where
T(A)ILS is heading to.
827

T(A)ILS developers's avatar
T(A)ILS developers committed
828
# 4 Security analysis
829
830

(It would be great to have links to peer reviews here.)