design.mdwn 61.3 KB
Newer Older
1 2
[[!meta title="Design: specification and implementation"]]

[[!toc levels=3]]
4 5 6 7 8

# 1 Introduction

In this document we present a specification of a *Privacy Enhancing
Live Distribution* (PELD) as well as an actual implementation of it called
*The Amnesic Incognito Live System* (in short: *Tails*).
10 11

By writing this document we intend to help third-parties do
security analyses of any given PELD and specifically of Tails.
13 14 15 16 17 18
We also wish to help establish best practices in
the field of PELD design and implementation, and thus raise the
baseline for all similar projects out there.

This document is heavily based on preliminary work that was done as
part of [Incognito 2008.1-r1
Tails developers's avatar
Tails developers committed
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
The *Bibliography* section has pointers to other inspiration and reference sources.

# 2 Privacy Enhancing Live Distribution Specification

**Note**: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"OPTIONAL" in this document are to be interpreted as described in
[RFC 2119](

## 2.1 Intent

Let us introduce what the PELD goals are: the features provided by the
PELD, the kind of user the PELD targets, and the (empty) room we think
the PELD fills in the Tor distributions landscape.

### 2.1.1 Privacy on the Internet

The Privacy Enhancing Live Distribution (or PELD for short) aims at providing
a software solution providing 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]('s state-of-the-art anonymizing
overlay network Tor.

Due to its deep dependency on Tor, the PELD defers the same possible
goals as Tor:

49 50
- The PELD does not try to conceal it is connected to the Tor network
  unless Tor bridge relays are used.
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
- The PELD is not secure against end-to-end attacks, such as
  end-to-end timing or intersection attacks.

Moreover, the PELD is likely to be affected by any feasible attack
against Tor; e.g. the PELD is not secure against some local attacks,
such as confirmation attacks based on website fingerprinting: see Lexi
and Dominik's *Contemporary Profiling of Web Users* [conference at
for details.

### 2.1.2 Protection from data recovery after shutdown

The PELD aims at protecting the user from post-mortem analysis
of the equipment (notably storage media and memory) he or
she runs the PELD on. It is impossible for such a system to determine
which information is sensitive and which is not. Thus, the PELD MUST
be amnesic by default:

- It is REQUIRED no trace is left on local storage devices unless the user
  explicitly asks for it: the PELD MUST take care not to use any
  filesystem or swap volume that might exist on the host machine hard
- The usage of encrypted removable storage devices (such as USB
  sticks) SHOULD be encouraged.
- Volatile memory MUST be erased on shutdown to prevent memory
  recovery such as [[!wikipedia cold boot attack]].
- Secure erasure of files and free disk space SHOULD be made easy.

### 2.1.3 Working on sensitive documents

The PELD aims at providing a "safe" environment to produce and
optionally publish sensitive documents. While the combination of
anonymous access to the Internet and resistance against future
equipment analysis does most of the job, some application-level
attacks deserve special treatment: e.g. tools needed to inspect and
cleanup metadata — such as EXIF data — in files SHOULD be available.

### 2.1.4 Portability

The PELD MUST 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 from the same single
distribution. In addition, while the PELD's main objective indeed is
to act as a traditional Live Distribution (i.e. a [[!wikipedia Live_CD]] or
[[!wikipedia Live_USB]]) it SHOULD also be compatible with popular
virtual machine technologies for users who simply want a sandboxed
environment within their usual operating system.

### 2.1.5 Target user

The PELD's target user is the average user in terms of computer
literacy; he or she does not necessarily control fully the computer
being used. Examples would be a public computer in a library, coffee
shop, university or a residence. We assume that the target user does
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 MUST provide strong anonymity with no
need of advanced configuration whatsoever. It MUST be made as
difficult as possible for the user to unknowingly compromise

### 2.1.6 Filling some empty room in the Tor distributions landscape

115 116
XXX: update

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
The PELD is meant to be complementary to other Tor distributions. It
has no such goal as replacing other existing tool that properly
fulfills its use cases.

The PELD fills an empty place alongside of other Tor distributions.
Using the PELD certainly requires the user to change more of his or
her habits than installing e.g. the [Tor Browser Bundle]( On the other
hand, the PELD currently is the only tool that makes it feasible to
use the Internet, and more generally computers, for certain activities
in contexts where the user cannot afford the risks involved by other
Tor distributions.

On the online privacy side of things, the PELD is aimed at offering
roughly the same protection level as e.g. the Tor Browser Bundle, but
provides a full-blown Tor-ified operating system instead of a few
selected and carefully configured applications; this e.g. allows to
safely download and open files using external applications, as
mentioned by the Torbutton warning popup when a user attempts such an
operation outside the PELD.

About protection from post-shutdown data recovery, thanks to its
amnesic-by-default behavior, the PELD can aim at providing a level of
protection only a fine-tuned Live operating system can offer. On the
contrary Tor distributions that rely on an untrusted underlying
operating system could hardly guarantee anything in this area,
regardless of the amount of resources and cleverness that is spent to
leave *less* traces on local storage:

- widespread operating systems and shipped Internet applications
  generally default to write all kinds of traces to local storage; Tor
  distributions that depend on such systems are therefore forced to
  adopt a blacklist approach to lessen the amount of traces left
Tails developers's avatar
Tails developers committed
149 150
  behind. Such an approach is known to be prone to human error,
  such as [[!tor_bug 7449]].
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
- widespread operating systems typically offer very few control knobs
  to userspace applications over their not-amnesic-by-default
  behavior, especially when run without any kind of administrator
  credentials. Tor distributions that depend on such systems generally
  have no choice but hope no undesired trace will be left e.g. in the
  system's swap file or partition.

The PELD amnesic feature also allows the user to safely perform
non-Internet activities, which is yet another distinctive trait
compared to other Tor distributions.

To sum up, one can be a Tor expert and carefully configure a
non-amnesic system to be as much Tor-ified as the PELD, but he or she
won't get the same post-mortem analysis protection.

### 2.1.7 Summary

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

## 2.2 Threat model

The goal of staying anonymous and keeping sensitive information
protected stands in direct conflict with the goals of several entities
"present" on the Internet. The following threat model is meant to
describe the intentions and capabilities of such attackers.
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 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 224 225 226 227 228 229 230 231 232 233 234 235 236 237

### 2.2.1 The goal of the attacker

The adversary may have one or more goals among the following ones.

- **Identify or locate the user, track his or her activities on the
  Internet**: information such as the User-Agent HTTP header, locale
  and especially IP address can all be used in various degrees to
  identify or locate the user, and to track his or her activities on
  the Internet.
- **Eavesdrop on sensitive data**: the Tor network only prevents the
  data from being traced (according to Tor's threat model) but does not
  protect it from eavesdropping.
- **Data recovery after system shutdown**:  "normal" operating systems
  keep a lot of traces about their users' Internet activities (notably
  browser cache, cookies and history) on local storage media;
  similary, working on a sensitive document with a "normal" operating
  system is very likely to leave traces of this document. User's data
  can remain on the equipment even after the machine is shut down; be
  it stored in the filesystem or in the memories, both RAM and swap,
  which might as well retain data (for example encryption keys or
  passwords). 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

The adversary may have capabilities needed to perform the following

- **Eavesdropping and content injection**: it is assumed that the
  adversary is non-global and has full control over the network
  traffic of some portion of the Internet (e.g. some Tor exit nodes,
  upstream routers of exit nodes, or the ISP that provides the
  Internet connection the user is sitting behind). The adversary is
  thus able to eavesdrop, modify, delete or delay parts or all of the
  user's traffic on the Internet.
- **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.
- **Exploit software vulnerabilities**: the attacker might be able to
  run arbitrary code by exploiting 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.
- **Physical access, live monitoring, post-mortem equipment
  analysis**: some users face adversaries with intermittent or
  constant physical access to the equipment they use. Users in
  Internet cafes, for example, face such a threat. This means the
  adversary might be physically monitoring the computer while the PELD
  is running on it. Moreover the adversary might raid the user at any
  moment and then confiscate and analyse the equipment, storage media
  and memory in particular.

## 2.3 Distribution

The PELD MUST 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
Tails developers's avatar
Tails developers committed
DVD with almost any DVD recording software available.
239 240

Also, it is RECOMMENDED to make it possible for end-users to verify
the downloaded PELD image's integrity using public-key cryptography.
242 243 244 245 246 247 248 249 250

## 2.4 Operational requirements

This section handles mostly the criteria that the PELD should be
portable and able to run in as many environments as possible.

### 2.4.1 Platform

The binaries MUST all be executable on the most common computer
Tails developers's avatar
Tails developers committed
hardware architecture(s). As of 2014, the x86 computer architecture
seems to be the obvious choice as the vast majority of personal
Tails developers's avatar
Tails developers committed
253 254
computers in use is compatible with it. The PELD SHOULD support UEFI.
Supporting widespread hardware architectures used in mobile
255 256 257 258
computers, such as phones, is also welcome.

### 2.4.2 Media

Tails developers's avatar
Tails developers committed
The PELD SHOULD be able to boot and run natively from either a DVD or a
260 261 262 263 264 265 266 267 268
USB drive. While running the PELD in native mode it MUST 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

In all circumstances, binaries, dynamic libraries and other executable
code susceptible to virus infections and similar MUST always be
completely write-protected, even when running from a writeable USB
medium. Such files SHOULD not even be modifiable temporarily, which
Tails developers's avatar
Tails developers committed
could be the case even when running from DVD if the filesystem is
270 271 272 273 274 275 276 277 278 279 280 281 282 283 284
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
MUST only be saved temporarily in memory (e.g. by use of something
like tmpfs or unionfs) unless the user explicitly enables some
persistence feature.

It is tempting to use the possibility to write back data when running
from USB in order to allow user settings to be persistent. If this is
considered, this feature MUST be optional and offer the possibility
to use strong encryption for the persistent storage.

### 2.4.3 Virtual machines

Tails developers's avatar
Tails developers committed
As an alternative to running the PELD natively from a DVD or USB, it
286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386
SHOULD also be possible to run it inside virtual machines.

Running the PELD is such a virtualized environment provides weakened
security compared to running it natively. This drawback is due to the
dependency on the host OS. When the PELD runs as a guest OS:

- The PELD cannot defend against keyloggers, viruses and other malware
  that could be present in the host OS. The user activities in the
  PELD might thus be under surveillance by an attacker who would
  control the host OS enough.
- The PELD can not guarantee anything with respect to writing to local
  storage: the host OS does its own memory management and can write to
  swap any part of the memory being used by the PELD without the user
  being told.

On the other hand, running the PELD inside a virtual machine is useful
in situations where the user is not in a position to run the PELD
natively, which often is the case with public computers. Additionally,
many users seem to prefer this mode of operation and would prefer to
use their usual operating system instead of rebooting to run the PELD
natively; that alone is a reason for making sure it works.

## 2.5 Other considerations

### 2.5.1 Maintainability

The procedure to update the PELD SHOULD NOT be prohibitive to provide
timely software updates that address issues related to security or
anonymity. A scripted, automatic build procedure is RECOMMENDED
over manually setting up things.

### 2.5.2 Sustainability

PELD development SHOULD be a team work rather than a one person work,
and the deep knowledge of this work SHOULD be shared among the team
members. Thus the development infrastructure SHOULD be designed and
deployed in order to share this knowledge.

### 2.5.3 Open-source transparency, easing peer review

For the sake of transparency the use of open-source software is
RECOMMENDED. Binary blobs SHOULD only be used when no good alternative
exists, which could be the case with certain hardware drivers or driver

Having third-parties analyze the PELD security is necessary to ensure
it is working as intended. It is thus REQUIRED 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 intends to achieve and how it does so SHOULD be
made available to reviewers.

Third-parties SHALL be able to reproduce a PELD implementation by
building it from the released source code and publicly available
information. The process MUST yield consistent results.

### 2.5.4 Easy feedback

In order to collect bug reports and wanted features, the PELD project
SHOULD offer easy ways for end-users to provide feedback to the
developers (email, web forum, bug tracker, shipped-within
application, ...). Efforts SHOULD be made to offer the most anonymous
(or at least pseudonymous) possible way to send this feedback.

## 2.6 Implementation requirements

### 2.6.1 Kernel requirements

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

- **Good hardware support** is REQUIRED: "good" is a sketchy word in a
  specification. The general idea is to include as much drivers for
  relevant hardware as possible, in particular for network cards
  (wired and wireless), video adapters and anything necessary for
  basic operation.
- **Support for a stateful firewall with packet filtering
  capabilities** is REQUIRED: it must somehow be able to sort traffic out for
  transparent proxying (mentioned in the next section) to work.
  Similarly, it must be able to identify and drop traffic destined to
  the Internet that is not supported by the Tor network, such as
  transport layer protocols other than TCP.
- **Security features** are RECOMMENDED: 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.

### 2.6.2 Network requirements

#### Firewall

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

- All non-TCP transport layer protocols SHOULD be dropped as they are
  not supported by the Tor network.
- All TCP traffic not explicitly targeting Tor SHOULD be redirected to
387 388 389
  the transparent proxy (i.e. to the `TransPort` as set in `torrc`);
  alternatively this traffic SHOULD be dropped (then only applications
  explicitly configured to use Tor will reach the Internet).
390 391 392 393 394 395 396 397 398 399 400 401 402 403 404
- All DNS lookups SHOULD be made through the Tor network (i.e.
  redirected to `DNSPort` as set in `torrc`).
- All IPv6 traffic SHOULD be forbidden as it is not supported by the Tor

Note that the above is not necessary (or desirable) for local network
(RFC1918) addresses; it is RECOMMENDED to special-case DNS queries
though as some home gateways and captive wifi portals reply the public
IP provided by the ISP when one asks information about themselves to
their DNS resolver (source: [The State of the DNS and Tor Union (also:
- TCP shim)](
thread on the or-talk mailing-list).

Any exception to these rules MUST be thoroughly thought through and
405 406 407
properly documented. If an action that is excepted from the above
rules is user initiated, that MUST be made obvious to the user, and
user opt-out MUST be offered, if possible.
408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438

#### Fingerprinting

Efforts SHOULD be made so that it is harder to fingerprint PELD users *as
being using the PELD*. Considering this goal can conflict with others,
trying to reach perfection in this domain is not necessarily

### 2.6.3 User interface and applications

#### General user interface

The user SHOULD be able to do all relevant things with easy-to-use
graphical interfaces. The PELD SHOULD present a solid, user-friendly
desktop environment with all the expected features after booting: file
management, system settings configuration, support applications etc.

#### Internet applications

At least clients for the following Internet activities MUST be

- **Web browsing**: since the web browser is arguably the most used
  end-user Internet application as well as the one that offers the
  largest attack surface, the Tor Project has spent significant
  resources on analyzing and mitigating the many pitfalls of modern
  web browsers with respect to anonymity: media plugins,
  browser-specific bugs, web technologies such as JavaScript, CSS and
  cookies, etc. Benefiting from this work is essential for maintaining
  anonymity, so it is REQUIRED to include only web browsers that are
  endorsed by the Tor Project, accompanied with any configurations,
439 440 441 442
  extensions/plugins, etc. that they recommend (for instance, Tor
  Browser Bundle). The PELD browser fingerprint SHOULD make the PELD
  users appear uniformly among Tor users with generally recommended
  configuration, such as Tor Browser Bundle users.
443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468
- **Email**: support for PGP or S/MIME is highly RECOMMENDED. Also,
  beware that the EHLO/HELO sent to the SMTP-server will contain the
  host's IP address in many email clients. The `Message-ID` headers and
  HTML/JavaScript email support are other usual leaking spots that
  MUST be taken care of.
- **Instant messaging**, including IRC and XMPP.
- **Secure Shell** client such as [OpenSSH](

Other RECOMMENDED clients for Internet activities include:

- **P2P file-sharing** such as BitTorrent: note, however, that large
  scale file-sharing activity in general is frowned upon in the Tor
  community as it consumes extreme amounts of network resources
  compared to other kinds of services.
- **Collaborative text editing** such as [Gobby](
- **Remote desktop** such as VNC or RDP.
- **Feed aggregator** for RSS/RDF, Atom and other widely spread feed

Given that these applications will be the user's interface to the
Internet, they MUST be chosen and configured cautiously, and with
security in mind. In general, as little information as possible SHOULD
leak about the user, the applications used and the system settings.

#### Document production applications

469 470 471 472 473 474
A great deal of communication over the Internet is done via the
distribution of different types of commonly used media and document
formats, so the PELD MUST contain the basic facilities for creating
and editing such formats. More specifically, at least the following
media and text production tasks MUST be possible using software
shipped by the PELD:
475 476 477 478 479 480 481

- **Word processing**
- **Bitmap and vector graphics**
- **Sound recording and editing**
- **Desktop publishing**
- **Printing and scanning**

Other RECOMMENDED media and text manipulation tools include:
483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503

- **Video editor**
- **Spreadsheet**
- **Presentation software**
- **Gettext catalogs (.po files) editor**

These applications SHOULD be compatible with widely spread file formats in
their domain.

#### Cryptographic tools

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 is the de-facto standard for these
tasks in the Free Software world. GUIs for managing keys and
performing 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://`).

Tools for creating and using encrypted storage containers are also RECOMMENDED.

504 505 506 507 508
A password manager SHOULD be included and allow one to store many
passwords in an encrypted database which is protected by a single key.
This is meant to encourage users to use strong passwords, and to
discourage password reuse.

509 510 511 512 513 514
Any cryptographic tool shipped in the PELD SHOULD by default use
up-to-date parameters with respect to the current commonly agreed best
practices: digests, ciphers and key sizes.

#### Tor

515 516 517
Only stable releases SHOULD be considered since Tor really is at the
core of the PELD.

Tails developers's avatar
Tails developers committed
Tor SHOULD be set up to enable its DNS server (`DNSPort`) to allow DNS
519 520 521 522
lookups through the Tor network; alternatively a local DNS server can
be configured to use Tor.

If transparent proxying (as opposed to dropping non-Tor traffic) was
Tails developers's avatar
Tails developers committed
chosen in the network section, then Tor MUST be set up to enable its
524 525 526 527 528
transparent proxy (`TransPort`, `TransListen`); alternatively any
transparent proxy configured to use Tor as the parent proxy can be

While there are many other interesting configuration possibilities
Tails developers's avatar
Tails developers committed
described in the Tor manual, care MUST be taken to avoid those that may
impair anonymity or security.
531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618

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
(`CookieAuthentication` preferably) to hinder attacks on the Tor

#### Hardened tool chain and compiling

As an addition to the security against exploitable vulnerabilities
provided by the kernel, compiling software with stack smashing
protection, Position Independant Executable (PIE) and similar compiler
security enhancements is RECOMMENDED. Note that some
compiler-level options may be necessary to take advantage of in-kernel
security features. Thus the use of a hardened tool chain might depend
on the vendor distribution used to build the PELD upon. If such
techniques are not widely deployed at this level, using them to build
the PELD can require a lot of time from its developers and impact its
ease of maintenance, which would make it harder for new contributors
to get involved in the project. For this reason, compile-time
hardening features should be carefully selected to balance the costs
they impose against the extra security they bring. If using a hardened
tool chain to build the PELD is deemed to require too much energy,
resources could be better spent pushing usage of such hardening
features in the base operating system.

#### "Virtual" input system

Since one goal of the PELD is to permit usage of untrusted computers
while preserving anonymity, measures MUST be taken against hardware
that might de-anonymize or facilitate recording of a user, such as
hardware [keyloggers]( Thus a
virtual keyboard (usable with the mouse) MUST be available.

#### 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 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 parameterized by far fewer
variables than in the case of a non-Live system.

Using an auxiliary entropy source such as
[haveged]( is thus

### 2.6.4 Usability

Security is usually hard to get. Therefore steps SHOULD be taken in
order to make users more comfortable with the PELD, and also to
educate users about specific risks and non-intuitive situations that
may affect their anonymity on the Internet.

#### Internationalization

The user MUST be able to easily select his or her language of
preference among a great number of widespread ones. User applications
SHOULD be localized to fit this preference, as SHOULD system settings
such as keyboard layout.

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.

#### Education and user help

The PELD SHOULD include an easy-to-read document explaining:

1. what the PELD goals (and non-goals) are. The PELD is no magic wand.
2. how to securely use the PELD and the bundled software.

As the user is assumed to only have the knowledge of an average
computer user, it will be required to explain some general security

Real-world experience demonstrates that the average user quite rarely
thinks about upgrading his or her PELD copy, and is often pretty happy
unknowingly 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.

## 2.7 The future

A few more or less well known issues shall be thought through so that
this specification can provide reasonable guidance about them.

619 620
### 2.7.1 Memory recovery attacks

Tails developers's avatar
Tails developers committed
622 623 624 625 626 627
aims at recovering a Live system's in-memory filesystem and partial
recovery of its previously deleted contents. Most current Live systems
do not protect against that kind of attacks: at best, they erase free
memory on shutdown, leaving intact in memory any data saved in the
unionfs/aufs ramdisk branch.

628 629 630
This was
on the or-talk mailing-list, and a new system that mitigates such
attacks is part of Tails 0.7 and newer.

633 634 635
This specification must warn about such matters.

### 2.7.2 HTTP keepalive
636 637 638 639 640 641 642 643 644 645

Quoting the [Live CD Best
document on the Tor wiki:

> OPTIONAL? To prevent the browser from keeping HTTP sessions open
> over existing circuits the following network settings should be
> applied. This will ensure that new circuits, such as requested via
> NEWNYM, will service subsequent HTTP requests.

646 647 648
The impact of HTTP keepalive and possible solutions are [being
on the tails-dev mailing-list.

650 651 652 653 654 655 656 657 658
### 2.7.3 Mounting of filesystems stored on removable devices

Some attacks recently put under the spotlights exploit vulnerabilities
in the desktop software stack that triggers automatic mounting,
display and files preview of filesystems stored on removable devices.

This specification must warn about such matters.

### 2.7.4 Miscellaneous
659 660 661 662 663 664 665 666

- FireWire is known to allow read access to the system memory, at
  least when such devices are allowed to use DMA (Linux: `options
  ohci1394 phys_dma=0` helps mitigating that).
- Bluetooth, IrDA and other network links might allow attacks.

# 3 Implementation

Tails is an implementation of the PELD specification above. It is
668 669 670 671
licensed under the GNU GPL version 3 or (at your option) any later

Critical parts of the configuration are based on the ones from
well-known and trusted sources, namely Tails ancestor
673 674
and the [Tor BrowserBundle](
This is for example the case for the firewall and Tor configurations.
676 677 678 679 680 681

**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 manage those risks.

## 3.0 Other Tails design documents
683 684 685

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

686 687
## 3.1 Download

sajolida's avatar
sajolida committed
See the [[installation section|install]] on [[Tails's website|/index]]
for download information. Published Tails images integrity can be
690 691 692 693
checked using OpenPGP detached signatures made with a key that is well
linked to the web-of-trust.

The sources are stored in a bunch of [Git](
Tails developers's avatar
Tails developers committed
repositories. The [[git page|contribute/git]] on the Tails website provides all
695 696
needed information to access these repositories.

The latest version of this document can be found on the Tails
698 699 700 701
website: [[!tails_website contribute/design]].

## 3.2 Software

Tails ships the following software. This list is not complete, but
703 704 705 706 707 708 709
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`

### 3.2.1 Core software
- [Debian GNU/Linux]( the base operating
  system, provides hardware detection, infrastructure. Please note
  that the Debian distribution does not provide or endorse Tails.
713 714
- [Tor]( anonymizing overlay network for
  TCP. Our intention is to always use the latest stable version.
- Vidalia is used to control Tor's behavior.

Being based in Debian, Tails benefits from its great package
management tools, facilitating its build and the inclusion of new
software. Sadly compile time options that would enhance Tails
security (`-fPIE`, `-fPIC`, `-fstack-protector` etc.) are not widely
used in Debian yet. Thus having them included in Tails would require
722 723
to recompile every package with the right compile-time options. This
would badly impact the development and build efforts required to
release Tails. As an alternative, efforts [have been
started](;[email protected])
726 727 728 729 730
to push usage of such hardening features in Debian.

A lot of security features have been implemented upstream at the
kernel level (ASLR, removal of `/dev/kmem`, `/dev/mem` protections,
various stack and heap hardening features, `/proc` or `/sys` not leaking
Tails developers's avatar
Tails developers committed
sensitive information, etc.), most of them being slowly integrated
into Debian. This is the reason why the Tails kernel has no more special
733 734 735 736
kernel security feature than the stock Debian kernel.

### 3.2.2 Other applications

See [[doc/about/features]].
738 739 740

## 3.3 Internationalization

Tails ships, as is, localization files provided by the installed
Debian packages. All available Tor Browser localization packages
Tails developers's avatar
Tails developers committed
are installed. Spell checking software and data is installed for the
set of best supported languages; it is usable at least is Tor Browser,
LibreOffice and gedit.

747 748 749
### 3.3.1 Input methods

Tails ships with IBus and a few engines (Anthy for Japanese, Pinyin
and Bopomofo for Chinese, and Hangul for Korean).

752 753
A login script prepares and configures IBus. When a Japanese,
Chinese or Korean locale is selected, this login script selects
the right default input method. GNOME starts the IBus daemon itself.

Still, since one may want to work on documents written in
Chinese, Japanese or Korean even when selecting English as their
758 759 760 761
preferred language, IBus is also started in other locales, with all
supported input engines pre-loaded.

IBus' environment variables are always exported on login to make this work.

- [[!tails_gitweb config/chroot_local-includes/usr/lib/systemd/user/tails-configure-keyboard.service]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-configure-keyboard]]

Tails developers's avatar
Tails developers committed
## 3.4 Notification of security issues and new Tails releases

768 769 770
Tails ships a script that checks if there are security issues that are
not fixed by any Tails release (and thus, affect the currently running
Tails regardless of its version). A desktop notification is displayed
for every such issue.

773 774 775 776 777 778 779 780
The connections are made to the Tails website through Tor, over HTTPS
with a pinned CA. The only piece of information leaked to the Tails
web server (apart of [[!cpan LWP::UserAgent]]'s specific User-Agent
and HTTP behavior) is the first two chars of the `LANG`
environment variable.

This script is run after the user has logged-in and Tor is
in known-working state.

- [[!tails_gitweb config/chroot_local-includes/usr/lib/systemd/user/tails-security-check.service]]
Tails developers's avatar
Tails developers committed
- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-security-check]]

785 786 787 788 789
Security issues that were fixed in a newer version of Tails are taken
care of by [[Tails Upgrader|contribute/design/incremental_upgrades]]
that tells the user whenever they should upgrade and leads them
through the necessary steps.

790 791
## 3.5 Feedback

Users can send feedback in several ways to Tails developers.
A [[!tails_redmine desc="task tracker"]] is available.
Users can also send email to the private [developers mailing
795 796 797 798
list]([email protected]) or to the public [support mailing
list]([email protected]).

A dedicated application called *WhisperBack*
is also available in every running Tails copy. WhisperBack allows
users to send anonymous or pseudonymous feedback via OpenPGP-encrypted
801 802
email. It is configured in Tails to use a Tor hidden service run by
Tails developers as the outgoing SMTP server. WhiperBack only sends
803 804 805 806 807 808 809 810
email over a STARTTLS session after carefully verifying the remote
SMTP SSL certificate. Some minimal information about the system is
gathered and sent along with the report; the reporting user can
opt-out of this though. Users can also provide an email address and an
OpenPGP public key in case further discussion is needed to address the
reported issue. WhisperBack's graphical interface fully supports
internationalization and is ready to be translated.

Tails developers's avatar
Tails developers committed
- [[!tails_gitweb_dir config/chroot_local-includes/etc/whisperback]]
- [WhisperBack source code](
813 814 815 816

## 3.6 Configuration

In this section we briefly present the setup of several key software
packages and system settings of Tails with respect to security and
818 819 820 821 822 823
anonymity. There are of course other minor tweaks here and there, but
those are mainly for usability issues and similar.

### 3.6.1 The Tor™ software

The Tor software is currently configured as a client only (onion
proxy). The client listens on a control port 9051
825 826
(using cookie authentication), as a transparent proxy on port 9040
(only used for remapped hidden services) and as a DNS server on port
827 828 829 830

The client listens on a few SOCKS ports (the rationale being detailed
on the [[Tor stream isolation design
page|contribute/design/stream_isolation]]): 9050, 9061, 9062 and 9151.
832 833

Only connections from localhost are accepted. It can be argued
834 835 836 837 838 839
that running a Tor server (onion router) would increase one's
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. The user can nevertheless easily choose to turn his or her
Tor client into a relay, thanks to the Vidalia graphical user
840 841 842 843 844 845

If a compromised software had access to the Tor control port,
an attacker who controls it could simply ask Tor the public
IP through the `GETINFO address` command.
To prevent this, access to the Tor control port is only
granted to the vidalia user, who is running Vidalia.
846 847
A filtering proxy to the control port exists, so
Torbutton still can perform safe commands like `SIGNAL NEWNYM`.

849 850 851 852 853 854 855
We disabled the default warning messages of Tor (`WarnPlaintextPorts`)
when connecting to ports 110 (POP3) and 143 (IMAP). These ports are used
for both plaintext and StartTLS connections. As more and more email
providers recommend and even enforce StartTLS on these ports, the effect
of these warnings were most of the time counterproductive as people had
to click through needlessly scary security warnings.

intrigeri's avatar
intrigeri committed
- [[!tails_gitweb config/chroot_local-hooks/06-adduser_vidalia]]
- [[!tails_gitweb config/chroot_local-includes/lib/systemd/system/tor-controlport-filter.service]]
intrigeri's avatar
intrigeri committed
- [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/restart-vidalia]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tor-controlport-filter]]
intrigeri's avatar
intrigeri committed
- [[!tails_gitweb config/chroot_local-includes/etc/tor/torrc]]

Tails developers's avatar
Tails developers committed
862 863
<a id="dns"></a>

864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884
### 3.6.3 DNS

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

### 3.6.4 HTTP Proxy

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

### 3.6.5 SOCKS libraries

tsocks and torify are installed. Since Tor-ification is done at a
lower level (in-kernel network filter, Tor-ified DNS), these tools are
actually unnecessary. They are solely included due to dependencies and
configured for completeness.

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

### 3.6.6 Network Filter

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

### 3.6.7 MAC address spoofing

See [[the dedicated design document|design/MAC_address]].
888 889 890

### 3.6.8 Host system swap

Tails takes care not to use any swap filesystem that might exist on
892 893 894
the host machine hard drive. Most of this is done at build time:
the `/sbin/swapon` binary is replaced by a fake no-op script, and
live-boot's `swapon` option is not set.
895 896 897 898 899

- [[!tails_gitweb config/chroot_local-hooks/05-disable_swapon]]

### 3.6.9 Host system RAM

[[!inline pages="contribute/design/memory_erasure" raw=yes]]
901 902 903

### 3.6.10 Host system disks and partitions

Tails takes care not to use any filesystem that might exist on
905 906
the host machine hard drive, unless explicitly told to do so by the
user. The Debian Live persistence feature is disabled by passing
`nopersistence` over the kernel command line to live-boot.
908 909 910

- [[!tails_gitweb config/amnesia]]

911 912 913 914 915
### 3.6.11 Filesystems stored on removable devices

Removable drives auto-mounting is disabled in Tails 0.7 and newer.

- [[!tails_gitweb config/chroot_local-includes/usr/share/amnesia/gconf/apps_nautilus.xml]]
916 917 918 919 920

### 3.6.11 Secure erasure of files and free disk space

Securely erasing files and free disk space is made easy by integrating
[secure-delete]( tools into the Nautilus file
921 922
manager, thanks to [Nautilus
923 924 925 926

### 3.6.12 Passwords

Two users are intended to be used for logins: `amnesia` and `root`.
927 928 929
None have a password by default; the `amnesia` user is
allowed to gain super user privileges, using `sudo`, if an
administrator password is set in tails-greeter.
930 931

The PELD specification recommends to prevent executable code to be
modifiable, even temporarily; Tails does not implement this
recommendation. Instead, thanks to the super user privileges being
available to the end-user, Tails makes it possible to modify or add
935 936 937
executable code by:

- upgrading bundled software: this allows (technical) users to protect
  themselves from serious security issues until an updated Tails is
939 940 941
- installing additional software: this helps achieving the PELD
  "Working on sensitive documents" goal by enabling users to perform
  tasks that need software not shipped in Tails.

Tails developers's avatar
Tails developers committed
Such modifications happen only in RAM, the user will remove the DVD/USB
945 946 947 948 949 950
when done and there are no services allowing logins from the network.

As a first step Tails has stopped
granting `sudo` privileges to the `amnesia` user by default.
Unless an administrator password is set in tails-greeter,
no root access is possible afterwards.

952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984
### 3.6.13 Tor Browser

Tails ships with the Tor Browser, which is based on Mozilla Firefox
and patched by the Tor Project for improved anonymity by reducing
information leaks, decreasing attack surface and similar. The actual
binaries etc. used in Tails are those distributed by the Tor Project,
but the configuration differs slightly, which is described below.

In Tails we diverge from the TBB's one-profile-only design, and
install the Tor Browser in a globally accessible directory used by all
browser profiles (and other XUL applications).

- [[!tails_gitweb config/chroot_local-hooks/10-tbb]]

The default profile is split from the binaries and application data:

- [[!tails_gitweb_dir config/chroot_local-includes/etc/tor-browser]]

As for extensions we have the following differences:

* Tails also installs the
  [Adblock plus](
  extension to protect against many tracking possibilities by removing
  most ads.

* Tails does not install the Tor Launcher extension as part of the
  browser. A patched Tor Launcher is installed for use as a
  stand-alone XUL application, though.

In Tails we do not use the `start-tor-browser` script, since it does a
lot of stuff not needed in Tails (error checking mainly) and isn't
flexible since it looks for the browser profile in a specific
place. Our custom script makes use of the global installation and also
985 986 987 988 989 990 991
makes sure the default profile is used as a basis. Any shared libraries
shipped inside the TBB are also used (via `LD_LIBRARY_PATH`) since
Debian stable often has too old versions to start the browser.

Whenever the user tries to start the Tor Browser before Tor is
ready, they are informed it won't work, and asked whether to start the
browser anyway:
992 993

- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tor-browser]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/generate-tor-browser-profile]]
- [[!tails_gitweb config/chroot_local-includes/lib/systemd/system/]]
996 997
- [[!tails_gitweb config/chroot_local-includes/lib/systemd/system/tails-wait-until-tor-has-bootstrapped.service]]
- [[!tails_gitweb config/chroot_local-includes/usr/lib/systemd/user/tails-wait-until-tor-has-bootstrapped.service]]
intrigeri's avatar
intrigeri committed
- [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/tor-has-bootstrapped]]
999 1000 1001 1002

Once Tor is ready to be used, the user is informed they can now use
the Internet:

- [[!tails_gitweb config/chroot_local-includes/etc/NetworkManager/dispatcher.d/]]

The remaining configuration differences can be found in:

- [[!tails_gitweb_dir config/chroot_local-includes/etc/tor-browser/preferences/0000tails.js]]
- [[!tails_gitweb config/chroot_local-hooks/12-install_browser_searchplugins]]
- [[!tails_gitweb config/chroot_local-hooks/12-remove_unwanted_browser_searchplugins]]
Tails developers's avatar
Tails developers committed
- [[!tails_gitweb config/chroot_local-hooks/13-override-tbb-branding]]
1011 1012
- [[!tails_gitweb config/chroot_local-hooks/14-add_localized_browser_searchplugins]]
- [[!tails_gitweb config/chroot_local-hooks/14-generate-tor-browser-profile]]
- [[!tails_gitweb config/chroot_local-hooks/15-symlink-places.sqlite]]

It should also be noted that the global TBB installation is also used
1016 1017 1018
for the [[Unsafe Browser]] and [[I2P Browser]], although they are
user-isolated and use separate profiles with very different

1020 1021 1022 1023 1024 1025 1026
### 3.6.14 Claws Mail

Claws Mail generates `Message-ID` headers using the hostname part of
the sender's email address, which does not leak usage of the PELD nor
any user location information.

It also always says `EHLO localhost` to the SMTP server instead of
1027 1028 1029 1030
disclosing the real IP address and hostname. This is achieved thanks
to tsocks, as Claws Mail leaks the hostname in the HELO/EHLO
message, resulting in a hostname leak in the `Message ID` and
`Received` email headers, when run with `torify` and `torsocks`.
1031 1032 1033 1034 1035 1036

Furthermore, any account a user creates is pre-configured to not use
HTML in order to get rid of a whole class of privacy concerns.

OpenPGP support is provided by the PGP/inline and PGP/MIME plugins.

Tails developers's avatar
Tails developers committed
- [[!tails_gitweb_dir config/chroot_local-includes/etc/skel/.claws-mail]] is copied to
  the user's `$HOME` at boot time
1039 1040
- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/torified-claws-mail]]
- [[!tails_gitweb config/chroot_local-includes/etc/tor/tor-tsocks-mua.conf]]
1041 1042 1043

### 3.6.15 Pidgin

Pidgin is configured in Tails to not log anything as well as not to reveal too
much of user activity by disabling reporting of online/away/typing
1046 1047 1048
status. Only IRC and Jabber/XMPP protocols are left available, to
avoid the usage of less well audited plugins. The Off-the-record
plugin is enabled
to help one-to-one conversations being as private and unrecordable as
1050 1051
possible. At boot a language confluxer generates a random looking default
nickname from the 2000 most common U.S. names (according to the U.S. social
Tails developers's avatar
Tails developers committed
security administration in the 1970's), which results in something Englishesque
1053 1054
sounding. The nickname is further made to look like a typical IRC nickname by
prefixing it with ^ or _ with probability 0.05, and changing it to leet speak
Tails developers's avatar
Tails developers committed
1055 1056 1057
with probability 0.05. When answering to CTCP requests, Pidgin does
not leak any information apart from PING and VERSION (`Purple IRC`),
which is deemed acceptable as there are probably other weirdness in
Tails developers's avatar
Tails developers committed
how the protocol is implemented, that disclose as much.

- [[!tails_gitweb config/chroot_local-includes/lib/live/config/2010-pidgin]]
Tails developers's avatar
Tails developers committed
- [[!tails_gitweb_dir config/chroot_local-includes/etc/skel/.purple]]
- [[!tails_gitweb config/chroot_local-hooks/09-remove_unsupported_pidgin_libs]]
1063 1064 1065

### 3.6.16 GnuPG

1066 1067 1068
GnuPG tools (namely: GPG itself and Seahorse) are configured to use
the sks-keyservers pool since it's reliable, well-synchronized with
the other HKP keyservers pools, and reachable over `hkps://`.

[[!tails_todo Monkeysphere]]'s `hkpms://` support will be used as soon as
1071 1072
possible in place of the hierarchical X.509 certification model.

1073 1074 1075 1076
GnuPG is configured accordingly to the [OpenPGP Best
e.g. to prefer non-outdated digest algorithms from the
SHA-2 family, to force exclusion of the version string in ASCII armored
1077 1078
output, to avoid automatically locating and retrieving keys, and to
disregard the preferred keyserver assigned to specific keys.
1079 1080

- [[!tails_gitweb config/chroot_local-includes/etc/skel/.gnupg/gpg.conf]]
- [[!tails_gitweb config/chroot_local-includes/etc/ssl/certs/sks-keyservers.netCA.pem]]
- [[!tails_gitweb config/chroot_local-includes/usr/share/amnesia/gconf/desktop_pgp.xml]]
- hkpms is available in Debian: [[!debpkg msva-perl]]

1085 1086 1087 1088 1089
### 3.6.17 Persistence feature

An opt-in data persistence feature is available in Tails 0.11 and
newer. See [[contribute/design/persistence]] for details.

### 3.6.18 Installation on USB sticks and SD cards

1092 1093 1094
An easy (read: not command-line based) way to install and upgrade
Tails on USB sticks and SD cards is available in Tails 0.11 and newer.
SD cards readers wired via SDIO are supported since Tails 0.21.
See [[design/installation]] for details.

1097 1098 1099 1100 1101 1102 1103 1104 1105
### 3.6.19 Wireless devices handling

Tails puts the wireless devices in a sensible state at boot time.

At boot time, Tails unblocks Wi-Fi, WWAN and WiMAX radios, unblocks
Bluetooth radio (so that it can be dealt another way:
[[todo/protect_against_external_bus_memory_forensics]]), and
soft-blocks all other kinds of wireless devices (e.g. UWB, GPS, FM).

- [[!tails_gitweb config/chroot_local-includes/lib/systemd/system/tails-set-wireless-devices-state.service]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-set-wireless-devices-state]]

1109 1110 1111 1112 1113 1114
### 3.6.20 OpenSSH

The OpenSSH client is configured to use the Tor SOCKS proxy, and to
prefer strong ciphers and MACs..

- [[!tails_gitweb config/chroot_local-includes/etc/ssh/ssh_config]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/connect-socks]]

### 3.6.21 Incremental upgrades
1118 1119

When a Tails release is out, Tails users are proposed to download and
1120 1121
apply a partial upgrade (that is, only what has changed between two
releases). See [[contribute/design/incremental_upgrades]] for details.
1122 1123
To start with, this upgrade mechanism may be only available for

### 3.6.22 Panel applets and GNOME Shell extensions
Tails developers's avatar
Tails developers committed

1127 1128 1129 1130 1131 1132
Tails ships a few custom GNOME panel applets and GNOME Shell

The shutdown-helper GNOME Shell extension provides two-clicks shutdown and
restart actions, as well as screen locking.

Tails developers's avatar
Tails developers committed
- [[!tails_gitweb_dir config/chroot_local-includes/usr/share/gnome-shell/extensions/[email protected]]]
Tails developers's avatar
Tails developers committed
1134 1135 1136 1137 1138 1139

The Tails OpenPGP applet allows to symmetrically and asymmetrically
encrypt and decrypt text, and to verify OpenPGP signatures.

- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/gpgApplet]]

1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164
### 3.6.23 DHCP hostname leaks

Tails prevents dhclient from sending the hostname over the network.

First, only the `keyfile` NetworkManager plugin is used; that is, the
`ifupdown` plugin is disabled:

* this is needed, because the only the `keyfile` plugin supports
  setting `dhcp-send-hostname` to false, while the `ifupdown` plugin
  retrieves the hostname to send from `/etc/hostname`;
* this is OK, because we actually don't use the functionality provided
  by the `ifupdown` plugin (that is, reading from
  `/etc/network/interfaces` -- that only configures the loopback
  connection in Tails, which is itself ignored by NetworkManager

Second, the NetworkManager `keyfile` plugin is configured to *not*
send the hostname over DHCP by default. Likely this can be overridden
on a per-connection basis if one really needs to change this.

Third, dhclient itself is told not to send the hostname. This is
needed because on Wheezy, NetworkManager runs dhclient with the `-cf
/var/run/nm-dhclient-eth0.conf` option, and generates that file by
concatenating `/etc/dhcp/dhclient.conf` with its own settings.

1165 1166 1167 1168 1169
Fourth, dhclient is told to override any hostname provided by the DHCP
server with `amnesia`. This is meant to prevent dhclient hooks,
NetworkManager and others from setting the hostname to a value
controlled by the DHCP server.

* [[!tails_gitweb config/chroot_local-patches/dhcp-dont-send-hostname.diff]]
1171 1172
* [[!tails_gitweb config/chroot_local-includes/etc/NetworkManager/conf.d/dhcp-hostname.conf]]
* [[!tails_gitweb config/chroot_local-includes/etc/NetworkManager/conf.d/plugins.conf]]

### 3.6.24 TCP timestamps
1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206

[[!rfc 1323 desc="TCP time stamps"]] allow for tracking clock
information with millisecond resolution. This may or may not allow an
attacker to learn information about the system clock at such
a resolution, depending on various issues such as network lag.
This information is available to anyone who monitors the network
somewhere between the attacked Tails system and the Tor entry nodes
being used. It may allow an attacker to find out how long a given
Tails system has been running, and to distinguish several Tails
systems running behind NAT and using the same IP address. It might
also allow to look for clocks that match an expected value to find the
public IP used by a user.

Hence, Tails disables this feature.

- [[!tails_gitweb config/chroot_local-includes/etc/sysctl.d/tcp_timestamps.conf]]

Note that TCP time stamps normally have some usefulness. They are
needed for:

* the TCP protection against wrapped sequence numbers; however, to
  trigger a wrap, one needs to send roughly 2^32 packets in one
  minute:  as said in [[!rfc 1700]], "The current recommended default
  time to live (TTL) for the Internet Protocol (IP) [45,105] is 64".
  So, we don't think this is a practical problem in the context
  of Tails.

* "Round-Trip Time Measurement", which is only useful when the user
  manages to saturate their connection. When using Tails, we believe
  that the limiting factor for transmission speed is rarely the
  capacity of the user connection.

1207 1208 1209 1210 1211 1212
### 3.6.25 Application isolation

Tails has some minimal [[contribute/design/application_isolation]] to
mitigate a bit the consequences of security issues in individual
applications being exploited by attackers.

1213 1214 1215 1216
### 3.6.26 wget

We wrap `wget` with `torsocks`, after unsetting the `http_proxy`
environment variable and friends, so that it talks directly to the Tor
SOCKS port.
1218 1219 1220

- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/wget]]

### 3.6.27 APT
1222 1223 1224 1225

During most of the ISO build process, APT uses the proxy configured
through `live-build` (that is, usually a local `apt-cacher-ng`).

1226 1227
However, at boot time, a hook does (a more elaborate version of)
`s,http://,tor+http://` in APT sources. Then, APT will use the
`tor+http` method, that is provided by [[!debpkg apt-transport-tor]].

- [[!tails_gitweb config/chroot_local-includes/lib/live/config/1500-reconfigure-APT]]

1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244
### 3.6.28 Electrum

We install the [Electrum]( Bitcoin client and the
default configuration tells it to use the default of Tor's
SOCKSPort:s, and sync the necessary parts of the Bitcoin blockchain
(as a lightweight client) from the default server pool using SSL.

There is also a persistence preset for the live user's `.electrum`
configuration folder, which stores the Bitcoin wallet, application
preferences and the cached Bitcoin blockchain.

- [[!tails_gitweb_dir config/chroot_local-includes/etc/skel/.electrum]]

## 3.7 Running Tails in virtual machines
1246 1247 1248

### 3.7.1 Current support

Tails may of course be run in virtual machines. Due to the
1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261
popularity of [VMWare]( we include
[open-vm-tools]( (an open-source
alternative to VMware tools) as well as special video drivers
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]( and
[QEMU](, by making sure that
these also work. In the case of VirtualBox both video and input
drivers are included, as well as the guest utilities.

### 3.7.2 Security concerns

Security concerns for all VMs are numerous. Tails therefore tries to
1263 1264 1265
detect whether it is run inside a VM and [[warns the
user|design/virtualization_support]] if it is.

### 3.7.3 Running Tails inside a Windows session

[[!tails_ticket 6083 desc="Potential work"]] may make it easier to
Tails developers's avatar
Tails developers committed
run the DVD/USB in a virtual machine inside a Windows session whenever
1270 1271 1272 1273 1274 1275 1276 1277 1278
native boot is impossible or not desirable. This probably will be
implemented by shipping a [QEMU]( or
[VirtualBox]( binary for Microsoft Windows.

## 3.8 Build process and maintenance

### 3.8.1 Build tools

The [Debian Live]( is a toolkit to build Live
systems based on Debian, such as Tails. Debian Live is designed to
automate the build process of the target distribution, which eases
Tails development and maintenance. As an added bonus, Debian Live
makes it possible for other people to build custom systems based on
Tails, e.g. to include additional software.

For detailed instructions on how to build and modify Tails, see
the [[contribute/build]] page and the [[contribute]] section on the wiki.
1287 1288 1289

### 3.8.2 Testing process

An automated build and test environment is useful to avoid
regressions in Tails, especially anonymity and security related
1292 1293 1294
ones. It also makes it easier for developers to work on Tails with
more confidence, and at release time to cut down the time needed for
quality assurance work.

1296 1297 1298 1299 1300
Tails' [[manual test suite|contribute/release_process/test]] is "run"
against Tails release candidates images before they are officially
published. Automating this test suite is [[partly
done|contribute/release_process/test/automated_tests]], and a work
in progress.
1301 1302 1303

### 3.8.3 Upgrades

Keeping Tor (stable releases only, unless the Tor core developers
recommend otherwise) and the Tor Browser up-to-date is a priority.