path: root/wiki/src/contribute/design
diff options
Diffstat (limited to 'wiki/src/contribute/design')
9 files changed, 457 insertions, 151 deletions
diff --git a/wiki/src/contribute/design/I2P.mdwn b/wiki/src/contribute/design/I2P.mdwn
index 789d584..ac989ea 100644
--- a/wiki/src/contribute/design/I2P.mdwn
+++ b/wiki/src/contribute/design/I2P.mdwn
@@ -11,10 +11,17 @@ be able to access eepsites from Tails.
-[I2P](https:/ has been included since Tails v0.7 with Iceweasel
+[I2P](https:/ has been included since Tails 0.7 with Iceweasel
preconfigured using FoxyProxy so that eepsites (`.i2p` TLD) are directed to
I2P. All other traffic gets routed through Tor.
+Starting with Tails 1.1.1, I2P is not enabled by default when Tails starts.
+In order to use I2P, a user must add the <span class="command">i2p</span> boot option
+to the <span class="application">boot menu</span>.
+Starting with Tails 1.2, I2P sites are accessed with the [[I2P Browser]].
+FoxyProxy is no longer installed in the Tor Browser..
<a id="design"></a>
@@ -35,9 +42,9 @@ started automatically. Some reasons behind this decision include:
3. some level of system compromise through 0-day exploits in the I2P
-Users that want to use I2P must start it manually from the `Applications` menu.
-In the future one may be able to start I2P during boot (see the [[!tails_todo
-boot_menu]] TODO page).
+Users that want to use I2P must enable it by addinng the <span class="command">i2p</span> boot option
+to the <span class="application">boot menu</span>. Once enabled, I2P will be started automatically by a NetworkManager hook
+(see [[!tails_gitweb config/chroot_local-includes/etc/NetworkManager/dispatcher.d/]]).
@@ -50,16 +57,16 @@ some years ago. This package includes an initscript which is configured by
default to start the I2P client as the `i2psvc` user.
The above package is installed but its init script is not automatically run
-during boot. Instead, an I2P shortcut has been added to the applications
-menu which the user can use to start the I2P init script manually. A
-side-effect of installing the actual I2P program into /usr is that
-automatic updates are disabled by the program since the installation
-directory is not writable by the `i2psvc` user.
+during boot. Instead, a NetworkManager hook will start I2P if the user
+specified "i2p" at the boot menu. A side-effect of installing the actual I2P
+program into /usr is that automatic updates are disabled by the program since
+the installation directory is not writable by the `i2psvc` user.
For better performance an exception has been made in the [[firewall
configuration|Tor_enforcement/Network_filter]] that grants direct access to the
network for the I2P user running the client so it can reach the I2P
-network directly, both through TCP and UDP.
+network directly, both through TCP and UDP. I2P is explicitly blocked from
+communicating with the LAN.
The I2P router is configured to run in hidden mode: killing I2P
ungracefully is bad for the I2P network, and this is most likely
@@ -73,70 +80,41 @@ this is a good reason to enable hidden mode, that is to disable
participating in I2P traffic:
[[!tails_gitweb config/chroot_local-hooks/16-i2p_config]].
-[[!tails_todo iceweasel_addon_-_FoxyProxy desc="FoxyProxy"]] has been installed
-system-wide, and the default iceweasel profile provides with a
-configuration handling the I2P integration. FoxyProxy's whitelist
-filter is used to make sure that the corresponding urls will be
-proxied appropriately.
-Below are the patterns that each url handeled by iceweasel will be
-matched against. These patterns will be tried in order, from top to
-bottom, until the first match is found:
-1. The I2P router console: urls matching the `*` wildcard
- pattern will get a direct connection to the local host so the I2P
- router console can be reached.
+Starting with Tails 1.2, I2P *eepsites* are accessed via the [[I2P Browser]], a
+modification of the [[Unsafe Browser]]'s setup scripts. See [[its page|I2P Browser]]
+for more information.
-2. The local *eepsite*: urls matching the `*` wildcard
- pattern will get a direct connection to the local host so the locally
- hosted eepsite can be reached.
-3. I2P eepsites: urls matching the
- `^https?://[-a-zA-Z0-9.]+\.i2p(:[0-9]{1,5})?(/.*)?$` regexp will be
- proxied through the local eepsite HTTP proxy run by the I2P client.
- Implementation note: FoxyProxy encloses the regexps between `^` and
- `$` itself since `isMultiLine="false"`, that's why the regexp in
- `foxyproxy.xml` lacks these chars.
+Disabling / Enabling I2P
-4. Tor HTTP(s): urls matching one of the `https://*` and `http://*`
- wildcard patterns will be proxied through polipo (and then its
- parent proxy, Tor).
+During the build process, [[!tails_gitweb config/chroot_local-hooks/97-remove_i2p]]
+moves I2P from its normal location at `/usr/share/i2p` to `/usr/share/tails/i2p-disabled`.
+The script [[!tails_gitweb config/chroot_local-includes/lib/live/config/2080-install-i2p]]
+checks for the string `i2p` in the kernel command line. If it is found, everything moved by
+[[!tails_gitweb config/chroot-local_hooks/97-remove_i2p]] is undone, making I2P available in the system.
-5. The rest: all remaining urls will be SOCKS5-proxied through Tor.
-Also, do note that Tails' [[netfilter-based
-blocking|Tor_enforcement/Network_filter]] ensures that no Internet
-traffic can be escape both Tor or I2P (and thus be non-anonymous) even
-if something is wrong in the above filters (or a future revision).
Ports allowed through the firewall
Services on I2P are accessed through tunnels built by I2P. Services that a user
hosts, such as an *eepsite* or *IRC Server* are accessed remotely via **Server Tunnels**.
-End users will access services using *client tunnels*. I2P is shipped with a
+End users will access services using **client tunnels**. I2P is shipped with a
few tunnels preconfigured and the ports that they use have exceptions added to
-ferm. These ports include:
-* 2727, BOB: [BOB]( is an application bridge allowing
- non-Java clients to interact with I2P.
-* 4444, I2P HTTP Proxy: Used to access sites with the `.i2p` TLD
-* 4445, HTTPS Outproxy tunnel: Disabled in by default in Tails in
- [I2PTunnel]( since all HTTPS traffic in Tails
- gets routed through Tor.
+ferm. The ports accessible to the `amnesia` user include:
* 6668, Tunnel to Irc2P: Used to connect to the main I2P-only IRC network
* 7656, [SAM]( SAM is an application bridge allowing
non-Java clients to use I2P. More information:
[SAMv1](, [SAMv2](,
-* 7657, I2P router console: The router console is accessible in the web browser at <>
-* 7658, local 'eepsite': Each I2P installation is configured out of the box
- with the possibility to host one's own website (or *eepsite*) on the I2P
- network. The eepsite will not be acessible remotely unless its
- [tunnel]( is started.
* 7659, SMTP Proxy: Tunnel to `smtp.postman.i2p`. More information is available from within I2P at [Postman's HQ](http://hq.postman.i2p/?page_id=10)
* 7660, POP3 Proxy: Tunnel to `pop3.postman.i2p`. More information is available from within I2P at [Postman's HQ](http://hq.postman.i2p/?page_id=11)
* 8998, MTN Proxy: Tunnel to `mtn.i2p2.i2p`, a [Monotone]( server.
+Note: These ports will only be opened if the user explicitly requests I2P at the boot prompt.
+See [[!tails_gitweb config/chroot_local-includes/etc/ferm/ferm.conf]] for details.
Features that require an administration password
@@ -150,6 +128,18 @@ will not be an issue unless one wants to
In order to utilize these features users need to set an
+Changes from upstream
+* i2cp, allowing java clients to communicate with I2P from outside of the JVM, is disabled
+* IPv6 is disabled
+* Outproxies are disabled
+* HiddenMode is set for all users
+* Updating I2P from within the I2P network is disabled; updates are done using the .debs
+* Inbound connections are disabled
+* I2P plugins are disabled
+* The webapp `susimail` will leave mail on the server
Package source and upgrading I2P
@@ -157,9 +147,15 @@ Tails uses the I2P (and deps)
[Debian packages prepared by KillYourTV](, the official I2P
Linux package maintainer as listed on the [I2P Team page](
The I2P source package and its binaries are imported into to our own
-[[APT repository|APT_repository]] into the devel or stable suite. The suite
+[[APT repository|APT_repository]] into the devel or stable suite. The suite
will depend on whether a major- or point-release is being prepared.
+## Prepare a Git topic branch
+Create a Git branch, forked off the branch into which the new packages
+shall eventually be imported into, and called e.g.
+`feature/i2p-0.n.m`. Push this branch.
## Check the binary packages
### Content
@@ -175,27 +171,26 @@ will depend on whether a major- or point-release is being prepared.
### Maintainer scripts
-Have a look at `*.{pre,post}{inst,rm}`.
+Have a look at `*.{pre,post}{inst,rm}` and `*.configure` maintainer
+scripts in each binary package.
## Import the packages
1. scp the source and binary packages to
1. move the uploaded files somewhere, and set permissions on it, so
that the `reprepro` user can read it
-1. use `reprepro includesrc` to import the source package(s)
-1. use `reprepro includedeb` to import the binary package(s)
+1. use `reprepro includedsc` to import the source package(s) into the
+ APT suite dedicated to the Git topic branch create above (e.g.
+ `feature-i2p-0.n.m`)
+1. use `reprepro includedeb` to import the binary package(s) into the
+ same dedicated APT suite
+1. build an ISO from the Git branch created above
+1. test this ISO
+1. merge the Git branch and APT suite as appropriate
Things to meditate upon
-* Pattern 4 will catch ftp://.* and redirect them to Tor through
- SOCKS5. This effectively breaks FTP completely, so there's room for
- adding a pattern above number 4 which matches ftp connections
- (i.e. `^ftp://.*`) and proxies them through some ftp proxy using Tor
- as its parent proxy. See [[!tails_todo FTP_in_Iceweasel]]. As an addition,
- at the moment (versions <=0.8) ftp does not work in I2P for
- technical reasons, so no pattern for that is needed.
* Do we want to enable the "Hidden mode" which completely disables
participating traffic?
@@ -216,7 +211,3 @@ Things to meditate upon
- there's no "cover-traffic", which may decrease the anonymity
-* Are the patterns used above correct for their intended purposes?
- Does the FoxyProxy setup in any way open up for attacks? See
- [[!tails_todo iceweasel_addon_-_FoxyProxy]].
diff --git a/wiki/src/contribute/design/I2P_Browser.mdwn b/wiki/src/contribute/design/I2P_Browser.mdwn
new file mode 100644
index 0000000..37e44ee
--- /dev/null
+++ b/wiki/src/contribute/design/I2P_Browser.mdwn
@@ -0,0 +1,56 @@
+Allowed Access
+The HTTP Proxy is set to on port 4444 with an exception made for
+ which does not go through the proxy. With this set-up, only eepsites (`.i2p`
+TLD), offline Tails documentation, and the router console are acessible from I2P Browser.
+Also, do note that Tails' [[netfilter-based
+blocking|Tor_enforcement/Network_filter]] ensures that no Internet
+traffic can escape I2P (and thus be non-anonymous), even if something is
+wrong in the above filters (or a future revision).
+Ports allowed through the firewall
+I2P is shipped with several preconfigured tunnels, and the ports used have had
+exceptions added to ferm. The ports accessible by the i2pbrowser user include:
+* 4444, I2P HTTP Proxy: Used to access sites with the `.i2p` TLD
+* 7657, I2P router console: The router console is accessible in the web browser at <>
+* 7658, local 'eepsite': Each I2P installation is configured out of the box
+ with the possibility to host one's own website (or *eepsite*) on the I2P
+ network. The eepsite will not be acessible remotely unless its
+ [tunnel]( is started.
+Note: These ports will only be opened if the user explicitly requests I2P at the boot prompt.
+See [[!tails_gitweb config/chroot_local-includes/etc/ferm/ferm.conf]] for details.
+The I2P Browser is run by a separate `i2pbrowser` user, which is only allowed
+to make TCP connections to the ports explicitly mentioned above. DNS lookups
+are prohibited.
+The I2P Browser is run inside a chroot consisting of a throw away
+aufs union between a read-only version of the pre-boot Tails
+filesystem, and a tmpfs as the rw branch. Hence, the post-boot
+filesystem (which contains all user data) isn't available to the
+I2P Browser within the chroot. The chroot and aufs union is created
+upon I2P Browser start, and is torn down after it exits, forcefully
+killing any remaining processes run from inside it.
+It should be noted that chroots are pretty weak jails, so an exploit
+could easily escape it and have access to the complete filesystem (as
+restricted for the `i2pbrowser` user). Hence, the reason for using a
+chroot is not for that purpose, but for separating its configuration from the rest of the Tails system.
+* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/i2p-browser]]
+* [[!tails_gitweb config/chroot_local-includes/usr/share/applications/]]
+* [[!tails_gitweb chroot_local-includes/lib/live/config/2080-install-i2p]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-activate-win8-theme]]
diff --git a/wiki/src/contribute/design/MAC_address.mdwn b/wiki/src/contribute/design/MAC_address.mdwn
index 938e06f..43733e6 100644
--- a/wiki/src/contribute/design/MAC_address.mdwn
+++ b/wiki/src/contribute/design/MAC_address.mdwn
@@ -376,15 +376,15 @@ Scripts:
### Potential for blocking the desktop
-The call of `udev settle` may block for up to 120 seconds (the default
+The call of `udevadm settle` may block for up to 120 seconds (the default
timeout) during Tails Greeter's PostLogin in case of some broken
hardware and/or crappy udev rules. In other words, the Tails desktop
may be blocked for this long, without any notification.
If this turns out to be a problem (currently it's only guesswork) we
-could make two `udev settle`:s, one with a short timeout (10 seconds)
+could make two `udevadm settle`:s, one with a short timeout (10 seconds)
and if it fails we show a notification and optimistically start
-another `udev settle` *in* *a* *sub-shell* so it doesn't block the
+another `udevadm settle` *in* *a* *sub-shell* so it doesn't block the
Tails desktop from starting any more.
For more, see this sub-thread on tails-dev:
@@ -412,7 +412,13 @@ leaks issue, in addition to other reasons for being discarded:
* NetworkManager hook: NM doesn't trigger events equivalent to
if-pre-up, so this isn't possible. See the commented parts in:
- /etc/NetworkManager/dispatcher.d/01ifupdown
+ `/etc/NetworkManager/dispatcher.d/01ifupdown`. Note that
+ NetworkManager 0.9.10 introduces pre-up hooks, *but* they're used to
+ "allow scripts to execute before NetworkManager announces
+ connectivity to applications" (according to a [blog
+ post](
+ by Dan William), that is, after network activity (e.g.
+ DHCP requests) has already occurred.
* systemd integration: We don't use this yet.
diff --git a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
index a7aeaff..33c4226 100644
--- a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
+++ b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
@@ -2,7 +2,7 @@ One serious security issue is that we don't know what software will
attempt to contact the network and whether their proxy settings are
set up to use the Tor SOCKS proxy or polipo HTTP(s) proxy correctly.
This is solved by blocking all outbound Internet traffic except Tor
-and I2P, and explicitly configure all applications to use either of
+(and I2P when enabled), and explicitly configure all applications to use either of
- [[!tails_gitweb config/chroot_local-includes/etc/ferm/ferm.conf]]
@@ -20,16 +20,17 @@ connections originating from the `debian-tor` Unix user.
#### I2P
-[I2P]( (*Invisible Internet Project*) is
+[I2P]( (*Invisible Internet Project*) is
yet another anonymizing network
(load-balanced unspoofable packet switching network) that provides
access to eepsites (.i2p tld); eepsites are a bit like Tor hidden
services. Some users would like to be able to access eepsites from
-Like the `debian-tor` user, the `i2p` user is allowed to connect
-*directly* to the Internet. See [[the design document dedicated to
-Tails use of I2P|I2P]] for details.
+Like the `debian-tor` user, the `i2psvc` user is allowed to connect
+*directly* to the Internet. Any rules granting the `i2psvc`user access are only
+applied if the user explicitly enables I2P at the boot prompt. See
+[[the design document dedicated to Tails use of I2P|I2P]] for details.
#### Unsafe Browser and the `clearnet` user
@@ -37,6 +38,13 @@ The `clearnet` user used to run the
[[contribute/design/Unsafe_Browser]] is granted full network access
(but no loopback access) in order to deal with captive portals.
+#### I2P Browser and the `i2pbrowser` user
+The [[contribute/design/I2P_Browser]] is run by the `i2pbrowser` user. This
+account is granted access to ports 4444, 7657, and 7658 on the loopback device *if*
+I2P is enabled at the boot prompt. Sites outside of I2P cannot be reached by
+the `i2pbrowser` user.
#### Local Area Network (LAN)
Tails short description talks of sending through Tor *outgoing
diff --git a/wiki/src/contribute/design/Unsafe_Browser.mdwn b/wiki/src/contribute/design/Unsafe_Browser.mdwn
index b79ec39..6eae7d6 100644
--- a/wiki/src/contribute/design/Unsafe_Browser.mdwn
+++ b/wiki/src/contribute/design/Unsafe_Browser.mdwn
@@ -14,8 +14,8 @@ Internet access seem required for avoiding this problem.
-* It must run a completely separate Iceweasel profile from the
- Torified browser's.
+* It must run a completely separate browser profile from the
+ Torified browser.
* It must be hard to start by mistake.
* It must be hard to mistake for the Torified browser.
* It must be configured to use the DNS provided by DHCP (which is required
@@ -42,8 +42,8 @@ when started:
0. Show a dialog asking the user for verification, while also briefly
explaining that the Unsafe Browser won't be anonymous.
0. "No" is the default answer, but if "Yes", we start a separate
- Iceweasel instance.
-0. Iceweasel is configured to use a theme with scary colors (red). To
+ browser instance.
+0. The browser is configured to use a theme with scary colors (red). To
not raise suspicion the scary theme is not used when Windows
camouflage is activated, but instead the normal Internet Explorer
theme is used.
diff --git a/wiki/src/contribute/design/application_isolation.mdwn b/wiki/src/contribute/design/application_isolation.mdwn
new file mode 100644
index 0000000..1c9b5b7
--- /dev/null
+++ b/wiki/src/contribute/design/application_isolation.mdwn
@@ -0,0 +1,266 @@
+[[!meta title="Application isolation"]]
+[[!toc levels=3]]
+For now, we are only aiming at filesystem resources isolation: that
+is, making sure that e.g. Pidgin cannot read the GnuPG keyring.
+Other types of resources, such as signals, X, ptrace, sockets, D-Bus
+etc. are [[not part of the isolation goals
+Tools and basic configuration
+For now, we have decided to use AppArmor to isolate applications,
+mostly because:
+* it is simple: AppArmor policy is relatively easy to understand,
+ improve, and audit;
+* it is the best supported [[!wikipedia mandatory access control]]
+ framework in Debian; it wasn't too hard to reach this point, and
+ there is quite some room for improvement via collaboration with
+ other distributions, most notably Ubuntu.
+The [[!debpts apparmor]] package is installed, and AppArmor is
+[[!tails_gitweb config/amnesia desc="enabled on the kernel
+Confinement profiles
+The AppArmor confinement profiles included in Tails come from:
+* individual Debian packages that ship confinement profiles, e.g.
+ Tor and Vidalia;
+* the [[!debpts apparmor-profiles]] package;
+* the [[!debpts apparmor-profiles-extra]] package.
+To get the full and current list, run `aa-status` as `root`
+inside Tails.
+Hacks to support the Live system usecase
+Most Live systems use a union filesystem to provide the operating
+system with a read-write filesystem, based on a read-only branch
+(typically, SquashFS) and a read-write one (most often, tmpfs).
+Unfortunately, AppArmor currently does not support union filesystems
+very well, because the LSM hooks do not allow it to distinguish
+between an access to the upper layer, and an access to the loop-backed
+underlying layer.
+So, we have to adjust profiles a bit to make them support the paths
+that are actually seen by AppArmor in the context of Tails:
+* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-home-tunable.diff]]
+* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-tor-profile.diff]]
+* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-user-tmp-abstraction.diff]]
+Below, we discuss various leads that might avoid the need for coming
+up with such adjustments, and maintaining it.
+Future work
+More confinement profiles
+As part of the [[!debwiki AppArmor desc="Debian AppArmor Team"]], we
+are working to get more well-tested and maintained profiles integrated
+into the distribution, and to improve cross-distribution collaboration
+in this area.
+<a id="more-resources"></a>
+Isolating more types of resources
+Once AppArmor 2.9 is released and the corresponding kernel patches are
+merged into Linux mainline, we will get support for mediating many
+more types of resources: D-Bus calls, sockets, signals and so on.
+[[Linux containers|application_isolation#linux-containers]] may also
+be a good way to isolate more types of resources.
+Using alias rules to avoid modifying profiles
+The most obvious trick to workaround AppArmor's lack of support for
+union filesystems is to use [alias
+such as:
+ echo 'alias / -> /lib/live/mount/rootfs/filesystem.squashfs/,' \
+ >> /etc/apparmor.d/tunables/alias
+However, a number of problems prevent this seemingly simple solution
+from just working in the context of Tails. The following discusses
+these complications, and a few possible solutions.
+### Bugs in alias rules implementation
+The implementation of alias rules is affected by severe bugs, such as
+There's preliminary work to fix this at
+Note that this code can still revert to the previous behaviour by
+passing the `-O old-alias` option to `apparmor_parser`.
+### Overlapping rules
+Alias rules can generate rules that overlap (and conflict) with
+existing ones, which can cause the policy to fail to compile.
+E.g. the `sanitized_helper` profile (sourced by the Evince
+profile and many others) contains this rule:
+ /lib{,32,64}/**/ld{,32,64}-*.so mrix,
+which, once combined with this alias:
+ alias / -> /lib/live/mount/rootfs/filesystem.squashfs/,
+will end up overlapping a lot of the rules generated for the alias.
+ /bin/* Pixr,
+results in a rule of:
+ /lib/live/mount/rootfs/filesystem.squashfs/bin/* Pixr,
+being generated, however since the alias command does not remove other
+rule sets, it only adds new rules. We end up with both:
+ /lib{,32,64}/**/ld{,32,64}-*.so mrix,
+ /lib/live/mount/rootfs/filesystem.squashfs/bin/* Pixr,
+which causes a conflict between `ix` and `Pix`.
+To workaround this problem, we would need to change the
+`/lib{,32,64}/**/ld{,32,64}-*.so mrix,` rule into:
+ /lib{32,64}/**/ld{,32,64}-*.so mrix,
+ /lib/{[^l],l[^i],li[^v],liv[^e],live[^/]}**/ld{,32,64}-*.so mrix,
+which allows the profile to compile, as the `x` conflict has
+been removed.
+Needless to say, this kind of regexp is painful to write, audit and
+maintain. Things could be nicer if AppArmor supported set operations;
+instead, we could do something like (syntax not finalized):
+ /lib/{^live**}/ld{,32,64}-*.so mrix,
+Other problematic overlaps include e.g. this rule from the
+`sanitized_helper` profile:
+ audit deny owner /**/* m,
+... that will take away the executable mmap permission from _all_
+applications under `/lib/live/` path, if the root user (who owns the
+file) tries to launch an application.
+This can possibly be fixed using [[rewrite
+rules|application_isolation#rewrite-rules]] instead of aliases, or by
+an update to the AppArmor permission merging logic that would give us
+a way to define that the alias rules should have priority in
+the union.
+Fixing such problems one after the other may be doable, but
+regardless: the way alias rules affect the policy as a whole,
+especially once combined with globing, would make our policy harder to
+understand, reason about, and audit.
+### Persistence
+It may be that more aliases are needed to support the bind-mounts set
+up by `live-boot` when using the [[contribute/design/persistence]]
+feature. It may even be that these aliases need to be dynamically
+added, in function of the persistence configuration... that is, at
+login time. If that was the case, then the entire policy would need to
+be recompiled at login time, which could make the user experience very
+painful, especially considering that alias rules vastly increase
+policy compilation time.
+### Increased policy compilation time
+Alias rules dramatically increase the policy compile time (e.g.
+100 seconds for the Evince profile, that can be brought down to
+8 seconds with the aforementioned rule change in the
+`sanitized_helper` profile).
+To mitigate that problem, we could:
+- either look at the rules and see if we can optimize it... which kind
+ of defeats the purpose of using alias rules in the first place to
+ avoid the need for modifying profiles;
+- or ship a cached pre-compiled policy. As long as the parser and
+ kernel are in sync, the policy can be pulled straight from the
+ cache, without any compilation. If the parser detects that the
+ policy is out of date, then the cache will be ignored and
+ compilation will happen. This is what is done for the Ubuntu phone.
+ Potential problems:
+ * if alias rules need to be added at login time, then the cache must
+ be invalidated, and the policy entirely recompiled;
+ * it remains to be researched how well this would work, once
+ combined with the [[additional software
+ packages|doc/first_steps/persistence/configure]] persistence
+ feature.
+<a id="rewrite-rules"></a>
+Using rewrite rules to avoid modifying profiles
+Other than alias rules, another option to avoid modifying profiles
+would be to use [rewrite
+They're basically the same as alias rules, except that it doesn't
+duplicate rules, so no conflicting rules are generated.
+It remains to be researched if rewrite rules would work in our use
+case: e.g. it might be that some files are seen as read from the
+SquashFS initially, and written to the overlay. If that would be the
+case, then we would need to duplicate some rules in profiles to add
+back some paths that were rewritten.
+is another kind of union filesystem, that seems to have much greater
+chances than aufs to be merged into Linux mainline some day.
+overlayfs works differently from aufs, in ways that give hope that it
+might be easier for AppArmor to support it natively.
+Once it's merged in Linux mainline, Debian Live could be made to
+support overlayfs as an alternative to aufs. One thing that should be
+checked is whether overlayfs supports stacking up more than one
+read-only branch, which we do need for the Tails
+[[contribute/design/incremental upgrades]] feature.
+Some ongoing work on AppArmor (labeling, extended conditionals) will
+help support overlayfs. Time will tell whether the result meets
+our needs.
+<a id="linux-containers"></a>
+Linux containers
+Using Linux containers for application isolation is being [[researched
+We owe a lot of thanks to John Johansen (<>)
+for his patience and support. Substantial parts of this document were
+adapted from explanations he provided to us.
diff --git a/wiki/src/contribute/design/persistence.mdwn b/wiki/src/contribute/design/persistence.mdwn
index d08588b..d3e521b 100644
--- a/wiki/src/contribute/design/persistence.mdwn
+++ b/wiki/src/contribute/design/persistence.mdwn
@@ -23,8 +23,8 @@ This is relevant for the following applications:
- GnuPG, SSH and OTR key pairs
- GnuPG configuration
- SSH client configuration
-- iceweasel certificate trust
-- iceweasel bookmarks
+- Tor Browser certificate trust
+- Tor Browser bookmarks
- Pidgin configuration
- MUA configuration
- printers configuration
diff --git a/wiki/src/contribute/design/stream_isolation.mdwn b/wiki/src/contribute/design/stream_isolation.mdwn
index a8b8edd..5190e6a 100644
--- a/wiki/src/contribute/design/stream_isolation.mdwn
+++ b/wiki/src/contribute/design/stream_isolation.mdwn
@@ -26,8 +26,8 @@ Tails:
Web Browser
-Until Torbrowser implements clever fine-grained stream isolation
-([[!tor_bug 3455]]), Iceweasel is merely directed to a dedicated SOCKS port.
+Until the Tor Browser implements clever fine-grained stream isolation
+([[!tor_bug 3455]]) it is merely directed to a dedicated SOCKS port.
Destination address/port -based circuit isolation
@@ -46,7 +46,7 @@ However:
before we ship it to the masses.
For performance reasons, we will start with *not* using
-`IsolateDestAddr`/`IsolateDestPort` for iceweasel we ship: nowadays,
+`IsolateDestAddr`/`IsolateDestPort` for the Tor Browser: nowadays,
loading a mere web page often requires fetching resources from a dozen
or more remote sources. (Also, it looks like the use of
`IsolateDestAddr` in a modern web browser may create very uncommon
@@ -77,7 +77,7 @@ Implementation
A few SOCKS ports are configured
-in [[!tails_gitweb chroot_local-includes/etc/tor/torrc]]:
+in [[!tails_gitweb config/chroot_local-includes/etc/tor/torrc]]:
* default system-wide `SocksPort` (9050): `IsolateDestAddr` and
`IsolateDestPort` enabled
@@ -85,15 +85,13 @@ in [[!tails_gitweb chroot_local-includes/etc/tor/torrc]]:
* dedicated `SocksPort` for Tails-specific applications (9062):
`IsolateDestAddr` and `IsolateDestPort` enabled
-* dedicated `SocksPort` for web browser (9151): no stream
+* dedicated `SocksPort` for web browser (9150): no stream
isolation options
* no specific isolation options for the `TransPort` ([[!tails_ticket 6378]])
Applications are configured to use the right SOCKS port:
-- [[!tails_gitweb config/chroot_local-includes/etc/iceweasel/pref/iceweasel.js]]
-- [[!tails_gitweb config/chroot_local-includes/etc/iceweasel/profile/foxyproxy.xml]]
-- [[!tails_gitweb config/chroot_local-includes/etc/iceweasel/profile/user.js]]
+- [[!tails_gitweb config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js]]
- [[!tails_gitweb config/chroot_local-includes/etc/init.d/htpdate]]
- [[!tails_gitweb config/chroot_local-includes/etc/tor/tor-tsocks-mua.conf]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-security-check]]
diff --git a/wiki/src/contribute/design/vagrant.mdwn b/wiki/src/contribute/design/vagrant.mdwn
index 62255b0..86a833b 100644
--- a/wiki/src/contribute/design/vagrant.mdwn
+++ b/wiki/src/contribute/design/vagrant.mdwn
@@ -46,67 +46,48 @@ called [Veewee].
Installing the requirements
-To build the *base box* from scratch using Veewee, you will need to get both
-Veewee and Vargant from Rubygems:
+Debian packages:
- # gem install --no-ri --no-rdoc vagrant
- # gem install --no-ri --no-rdoc veewee
+ sudo apt-get install ruby ruby-dev rubygems build-essential libxslt1-dev \
+ libxml2-dev virtualbox linux-headers-amd64
-*Note:* Unfortunately, using `gem --user` does not work. The `basebox`
-subcommands that is made available by Veewee never shows up in Vagrant.
-That needs to sorted out upstream.
+Veewee isn't packaged in Debian, so we install the Ruby Gem as the
+user that is gonna build the basebox:
-*Note:* Installing the Veewee gem will install the Vagrant gem, even
-if the Debian package is installed.
-Running Veewee
-Running Veewee has been automated using Rake. So creating the *base box* is
-just a matter of running:
- $ http_proxy="http://proxy.lan:3142" rake basebox:create_basebox
-Obivously, you can drop the `http_proxy` part if you don't have one.
-The rest should be fully automatic, and leave you with a `` file in
-the `vagrant` directory.
+ gem install --user --no-ri --no-rdoc veewee
Update the distributed *base box*
-The *base box* on Tails mirrors is expected to lie at
-Do not forget to update the corresponding SHA256 sum in `vagrant/Vagrantfile`.
-In details
-To create the *basebox* from the `squeeze` template (in `definitions`
-directory), the command is the following:
- $ vagrant basebox build squeeze
-> *Note:* It looks like the current version of the `virtualbox` gem is not
-> compatible with VirtualBox 4.0.x that is in `squeeze-backports`. Using
-> a hand made backport of virtualbox 4.1.12-dfsg-2 worked fine.
-After issuing that command, Veewee will download the boot ISO image,
-drive the debian-installer using [preeseding] and run `` that
-will take care of seting up the environment expected by Vagrant.
-In order to support local HTTP proxy, the `preseed.cfg` is generated from an
-ERB template during the Rake task `create_preseed_cfg`.
-Once the initial setup is done, it is worthwhile to see if the *basebox*
-fits Vagrant requirements. Veewee ships with an automated test suite:
- $ vagrant basebox validate squeeze
-If everything goes well, then, great, we have our *basebox*. Let's export
-it to a `.box` file that Vagrant can use:
- $ vagrant basebox export squeeze
+After issuing the commands below, Veewee will download the boot ISO
+image, drive the debian-installer using
+and run `` to take care of seting up the environment
+expected by Vagrant.
+ ORIG_BOXNAME=tails-builder
+ DATE="$(date +%Y%m%d)"
+ sed -i "s/tails-builder-[0-9]\{8\}/${BOXNAME}/" vagrant/Vagrantfile
+ mkdir -p "${VEEWEE_SRC}"/definitions
+ cp -a vagrant/definitions/${ORIG_BOXNAME}" vagrant/definitions/${BOXNAME}"
+ veewee vbox build "${BOXNAME}"
+ vboxmanage controlvm "${BOXNAME}" acpipowerbutton
+Wait until VM shuts down, then:
+ veewee vbox export "${BOXNAME}"
+ vboxmanage unregistervm "${BOXNAME}" --delete
+ rm -rf definitions/"${BOXNAME}"
+ CHECKSUM="$(sha256sum ${BOXNAME}.box | grep -o '^\w\+')"
+ sed -i -e "s/^BOX_CHECKSUM = .*$/BOX_CHECKSUM = '${CHECKSUM}'/" \
+ vagrant/lib/tails_build_settings.rb
+ sed -i "s/tails-builder-[0-9]\{8\}/${BOXNAME}/" \
+ vagrant/lib/tails_build_settings.rb vagrant/Vagrantfile
+ git commit vagrant -m "Updated Vagrant basebox."
+Then `$` will be placed in tails source root,
+and all needed changes committed to the current checked out branch in
+Tails sources. The basebox should be uploaded to the Tails mirrors at
+`$`, as
+define defined in `vagrant/Vagrantfile`.