path: root/wiki/src/contribute/design
diff options
Diffstat (limited to 'wiki/src/contribute/design')
12 files changed, 126 insertions, 31 deletions
diff --git a/wiki/src/contribute/design/I2P_Browser.mdwn b/wiki/src/contribute/design/I2P_Browser.mdwn
index 37e44ee..b2ad411 100644
--- a/wiki/src/contribute/design/I2P_Browser.mdwn
+++ b/wiki/src/contribute/design/I2P_Browser.mdwn
@@ -51,6 +51,8 @@ Code
* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/i2p-browser]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
* [[!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/Time_syncing.mdwn b/wiki/src/contribute/design/Time_syncing.mdwn
index ad1f59e..33ebbb0 100644
--- a/wiki/src/contribute/design/Time_syncing.mdwn
+++ b/wiki/src/contribute/design/Time_syncing.mdwn
@@ -24,16 +24,14 @@ using Tor so we can make Tor usable.
In short this is how time syncing is performed when Tails starts:
0. Start Tor. If Tor is already working, skip to HTP step.
-0. Let Tor fetch a consensus (wait 150 seconds twice, restarting Tor
+0. Let Tor fetch a consensus (wait up to 150 seconds twice, restarting Tor
in between).
0. If the time is too badly off, the authority certificate may not be
- valid any more, so we set the system time to the Tails release date, which
- will guarantee that the certificates are valid. Then we SIGHUP Tor
- and wait for a new consensus again.
-0. Set the system time to an initial "guess" based on the Tor
- consensus validity period, no matter if the consensus was verifiable
- or not.
-0. Restart Tor, which now should be working.
+ valid, so we set the system time to the `valid-after` of the unverified
+ consensus Tor fetched for us, which will guarantee that the certificate
+ and consensus are all valid. Then we restart Tor (since it behaves badly
+ with time jumps during the early bootstrap stages) and wait until it
+ accepts the consensus and finishes the bootstrap.
0. Run HTP (see below) through Tor to get a more correct system time.
A notification is shown while the whole process is running,
@@ -127,7 +125,7 @@ custom version of the Perl HTP client into
[[!tails_gitweb config/chroot_local-includes/usr/local/sbin/htpdate]].
The repository we copied this script from can be found there:
- git://
For reasons detailed bellow, this version of htpdate uses curl for all
of its HTTP operations.
diff --git a/wiki/src/contribute/design/Tor_enforcement.mdwn b/wiki/src/contribute/design/Tor_enforcement.mdwn
index 33bcab9..d13db74 100644
--- a/wiki/src/contribute/design/Tor_enforcement.mdwn
+++ b/wiki/src/contribute/design/Tor_enforcement.mdwn
@@ -10,11 +10,6 @@ DNS
[[!inline pages="contribute/design/Tor_enforcement/DNS" raw=yes]]
-HTTP Proxy
-[[!inline pages="contribute/design/Tor_enforcement/Proxy" raw=yes]]
Network filter
diff --git a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
index 33c4226..3c067ad 100644
--- a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
+++ b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
@@ -1,6 +1,6 @@
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.
+set up to use the Tor SOCKS proxy correctly.
This is solved by blocking all outbound Internet traffic except Tor
(and I2P when enabled), and explicitly configure all applications to use either of
diff --git a/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn b/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn
deleted file mode 100644
index 7389363..0000000
--- a/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Polipo provides with caching HTTP proxy functionality. It contacts the
-Tor software via SOCKS5 to make the real connections: [[!tails_gitweb
-In case the firewall is buggy or not properly started, proxy settings
-are used as part of a defence in depth strategy:
-- The standard `http_proxy` and `HTTP_PROXY` environment variables are
- globally set in [[!tails_gitweb
- config/chroot_local-includes/etc/environment]] to point to Polipo.
diff --git a/wiki/src/contribute/design/UEFI.mdwn b/wiki/src/contribute/design/UEFI.mdwn
index c6b587b..9ecd88f 100644
--- a/wiki/src/contribute/design/UEFI.mdwn
+++ b/wiki/src/contribute/design/UEFI.mdwn
@@ -30,8 +30,8 @@ Non-goals
in Legacy BIOS boot mode from hybrid ISO cat'd on a USB device.
If the firmware supports it, this can be done on the same computer;
else, from another computer.
-* 32-bit UEFI boot: this hardware is rare and mostly obsolete these
- days
+* 32-bit UEFI boot: this hardware is rare; we have [[!tails_ticket
+ 8471 desc="plans to reconsider this decision"]], though.
* [[blueprint/UEFI Secure boot]] is not part of this plan.
Picking technical solutions that leave room for it would be a great
bonus, though.
diff --git a/wiki/src/contribute/design/Unsafe_Browser.mdwn b/wiki/src/contribute/design/Unsafe_Browser.mdwn
index 6eae7d6..412eded 100644
--- a/wiki/src/contribute/design/Unsafe_Browser.mdwn
+++ b/wiki/src/contribute/design/Unsafe_Browser.mdwn
@@ -83,6 +83,7 @@ Code
* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/unsafe-browser]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
* [[!tails_gitweb config/chroot_local-includes/usr/share/applications/]]
* [[!tails_gitweb config/chroot_local-includes/etc/sudoers.d/zzz_unsafe-browser]]
* [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-activate-win8-theme]]
diff --git a/wiki/src/contribute/design/application_isolation.mdwn b/wiki/src/contribute/design/application_isolation.mdwn
index 1c9b5b7..8595da0 100644
--- a/wiki/src/contribute/design/application_isolation.mdwn
+++ b/wiki/src/contribute/design/application_isolation.mdwn
@@ -37,7 +37,10 @@ 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.
+* the [[!debpts apparmor-profiles-extra]] package;
+* the [[!debpts torbrowser-launcher]] package:
+ - [[!tails_gitweb config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch]]
+ - [[!tails_gitweb config/chroot_local-hooks/19-install-tor-browser-AppArmor-profile]]
To get the full and current list, run `aa-status` as `root`
inside Tails.
@@ -59,11 +62,85 @@ 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-totem-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.
+<a id="ux"></a>
+User experience matters
+Currently, no good way exists to let the user choose an arbitrary file
+each time they want to open or save one, without leaving the AppArmor
+profiles wide-open and then much less useful.
+Solutions to this problem are work-in-progress in various upstream
+places (e.g. AppArmor and GNOME sandboxed applications). The idea is
+generally to introduce a privileged mediation layer between
+applications, the GTK file chooser and the filesystem. So, some day we
+can solve this problem in better ways, but we're not there yet.
+Tor Browser
+As of Tails 1.3, the Tor Browser is somewhat confined with AppArmor.
+Given we cannot seriously allow the Tor Browser to read and write
+everywhere in the home and persistent directory, we had to allow it to
+read/write files from/to one specific directory, and make it so the
+user experience is not hurt too much.
+Now, let's say we have a downloads/uploads directory that's shared
+between the Tor Browser, the file browser, and all non-confined
+applications. That directory is called `~/Tor Browser/`, and a GTK
+bookmark pointing to it is created at login time:
+* [[!tails_gitweb config/chroot_local-includes/etc/xdg/autostart/create-tor-browser-directories.desktop]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/create-tor-browser-directories]]
+* [[!tails_gitweb config/chroot_local-includes/etc/xdg/autostart/add-GNOME-bookmarks.desktop]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/add-GNOME-bookmarks]]
+Then, we have a usability issue: the space available in that directory
+is limited by the free system memory (RAM). So large file downloads
+may fail. Note that Firefox doesn't mind letting users start
+downloading a file to a directory that hasn't enough room available to
+store it entirely, so this problem is not specific to downloading to
+an amnesiac directory.
+Still, we thought it would be good to allow users to download large
+files from Tor Browser to their persistent volume, so we have
+introduced a second downloads/uploads directory: `~/Persistent/Tor
+Browser/`, that is created whenever the "Personal data" (aka.
+`~/Persistent/`) persistence feature is activated. In that case, if
+persistence was activated read-write, another GTK bookmark pointing to
+that directory is created at login time.
+This seemed to be better than introducing yet another persistence
+feature (e.g. for `~/Tor Browser/`): having downloads be either always
+amnesiac or always persistent (unless you restart or do stuff outside
+of the browser) would seem like a regression, since it breaks one of
+the core Tails properties. And forcing it to be a persistent folder by
+default actually has security issues since secure deletion does not
+work as expected on Flash memory. So, we decided that users need to
+have the option to download either to an amnesiac (`~/Tor Browser/`)
+or persistent (`~/Persistent/Tor Browser/`) place, like it was the
+case previously.
+So, in a nutshell we give Tor Browser access to:
+* `~/Tor Browser/`, which is amnesiac, as everything else in Tails by
+ default; this is set to be the default download directory
+ ([[!tails_gitweb config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js]]);
+* `~/Persistent/Tor Browser/`, that is persistent, and only created
+ when `~/Persistent/` is itself persistent and read-write.
+Note that we don't call these folders "Downloads", because e.g.
+if someone creates an ODT file and wants to upload it, having to move
+it to a folder called "Downloads" sounds really weird.
Future work
diff --git a/wiki/src/contribute/design/hybrid_ISO.mdwn b/wiki/src/contribute/design/hybrid_ISO.mdwn
index 6fa0a5f..554143e 100644
--- a/wiki/src/contribute/design/hybrid_ISO.mdwn
+++ b/wiki/src/contribute/design/hybrid_ISO.mdwn
@@ -1,10 +1,22 @@
Since 0.5 up to 0.10.2, every published Tails i386 ISO image has been a hybrid one:
-- it can be burnt to a CD;
+- it can be burnt to a DVD;
- it also contains a full disk image (including partition table) and
can thus be copied (using `dd`) to a USB stick; the USB stick's
content is lost in the operation.
+Then, we stopped hybrid'ing the ISO images we publish, and started
+again in Tails 1.3.
+Nowadays, we pass the `-h 255 -s 63` options to `isohybrid`, as
+advised by the syslinux community for images between 1 GiB and
+4 (?) GiB.
+What follows comes from the Tails 0.10 days.
Successful tests:
* boot the resulting `test.iso` as a normal optical drive in
diff --git a/wiki/src/contribute/design/incremental_upgrades.mdwn b/wiki/src/contribute/design/incremental_upgrades.mdwn
index 5b434e1..3ca97d5 100644
--- a/wiki/src/contribute/design/incremental_upgrades.mdwn
+++ b/wiki/src/contribute/design/incremental_upgrades.mdwn
@@ -577,6 +577,15 @@ Both with the old and new Tails upgrade systems, mounting such an
attack requires either to take control of the Tails website or to
break the SSL/TLS connection between the client and the server.
+This attack is slightly mitigated by the fact that we are announcing
+new releases in other ways:
+* one that does not rely on our website at all (Twitter);
+* one that does not rely on our website to be safe at the time Tails
+ Upgrader checks for available upgrades, as long as it was safe at
+ the time the new release was published (<>
+ announce mailing-list).
The move to a secure upgrade system, such as TUF, would make this
stronger, thanks to short-lived signatures on meta-data.
@@ -599,6 +608,10 @@ The upgrade-description files downloader and verifier could refuse to
download upgrade-description files bigger than some reasonable
constant, but this is not implemented yet.
+This attack, when performed against the upgrade-description files
+downloader and verifier is slightly mitigated in the same way as
+"Indefinite freeze attacks" are.
### Slow retrieval attacks
> An attacker responds to clients with a very slow stream of data that
diff --git a/wiki/src/contribute/design/installation.mdwn b/wiki/src/contribute/design/installation.mdwn
index cca2d6f..3fa4a51 100644
--- a/wiki/src/contribute/design/installation.mdwn
+++ b/wiki/src/contribute/design/installation.mdwn
@@ -37,7 +37,7 @@ Mode of operation and booting methods
In order to be able to have non-destructive upgrades, blind overwrites
(using `dd` or similar raw copy methods) of the boot media is not possible
-(even if Tails [[shipped hybrid ISO
+(even when Tails [[ships hybrid ISO
Two alternatives booting methods have been investigated:
diff --git a/wiki/src/contribute/design/memory_erasure.mdwn b/wiki/src/contribute/design/memory_erasure.mdwn
index 54a3e9a..6dac6f4 100644
--- a/wiki/src/contribute/design/memory_erasure.mdwn
+++ b/wiki/src/contribute/design/memory_erasure.mdwn
@@ -93,13 +93,20 @@ physically removed.
#### Making sure needed files are available
-The memlockd daemon, appropriately configured, ensures every file
+The `memlockd` daemon, appropriately configured, ensures every file
needed by the memory erasure process is locked into memory from boot
to memory erasure time.
+Care have to be taken during the shutdown sequence, as `memlockd` is normally
+unloaded before the `kexec` happens. This is done by preventing `memlockd` to
+be stopped, and also by adding memlockd PID to the list of process that are
+omitted by the `sendsigs` script (responsible for sending TERM and KILL signals
+to remaining processes).
- [[!debpts memlockd]]
- [[!tails_gitweb config/chroot_local-includes/etc/memlockd.cfg]]
- [[!tails_gitweb config/chroot_local-patches/keep_memlockd_on_shutdown.diff]]
+- [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-reconfigure-memlockd]]
#### User interface