Re: [T(A)ILS-dev] Specification and security design document

Delete this message

Reply to this message
Autor: alan
Data:  
Dla: tails-dev
Temat: Re: [T(A)ILS-dev] Specification and security design document

El Tue, 14 Dec 2010 10:28:44 -0800
alan@??? escribió:
> From: intrigeri <intrigeri@???>
> To: tails-dev@???
> Date: Tue, 14 Dec 2010 10:28:04 -0800
> Enc: unencrypted
> Sig: No signature
>
> Hi,
>
> I've starting working on our specification and security design
> document, based on good old Incognito's one:
>
>     https://amnesia.boum.org/contribute/design/draft/

>
> Help, critics and comments are of course welcome.
>
> Bye,


Hi,

I just read the draft and it's great. Just a few comments, even thought
I don't know everything about Tails' internals.

1. First, about what you call the « post-mortem analysis ». I like the
term but I want to know whether it is a canonical term for security
experts or something that might need a bit more explanation.

Then, apart from the threat model, the document is not very explicit
about this issue. There might not be much to say but I think that it
should at least be mentioned in the requirements, part 2 :
- What is required for a PELD to prevent from post-mortem analysis?
- How do we think this should be provided?

Again in part 3, while presenting the implementation we should explain
more about what Tails does to achieve that. There is a paragraph on
host system RAM but I guess we can find more to explain, like :
  - I could imagine that some LiveDistros detect the swap areas and use
    them.  Do we ? ;)
  - I could imagine that some LiveDistros read the disks and possibly
    mount the available partitions automatically. Same thing.
  - I wonder how Tails addresses the requirements in 2.1.2, for example
    this one : « The usage of encrypted removable storage devices (such
    as USB sticks) should be encouraged. »


I think this whole post-mortem analysis thingie is the real difference
to put forward while talking to the Tor people ; bringing their privacy
concerns further than just the Internet connection. You can be a Tor
freak and get the same Tor configuration as Tails on your own system
but you won't get the same post-mortem analysis protection.

2. In 3.2.3, there is :

- [cryptsetup](http://code.google.com/p/cryptsetup/) ensures storage
encryption using [LUKS](http://en.wikipedia.org/wiki/LUKS)

Should we rather say 'offers' instead of 'ensures'. Is Tails using LUKS
if not asked to do so ?

3. You'll find attached to this mail a very small amount of aesthetics
and language fixes. I'm not sure whether there is a native English
speaker in the team but, well, we would a review at some point.

Cheers,

--
sajolida




--
From 0cb22374e89208e43bcee45cc3fc21db24434216 Mon Sep 17 00:00:00 2001
From: T(A)ILS developers <amnesia@???>
Date: Mon, 20 Dec 2010 22:49:22 +0100
Subject: [PATCH] Design draft: small language fixes.

---
wiki/src/contribute/design/draft.mdwn | 38 ++++++++++++++++----------------
1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/wiki/src/contribute/design/draft.mdwn b/wiki/src/contribute/design/draft.mdwn
index cf7c886..b6627a8 100644
--- a/wiki/src/contribute/design/draft.mdwn
+++ b/wiki/src/contribute/design/draft.mdwn
@@ -98,9 +98,9 @@ attackers.
- **Identify the user's activities on the Internet**: Information such
as user-agent, locale and (especially) IP address can all be used in
various degrees to identify the user.
-- **Eavesdrop on sensitive data**: Sensitive data sent through the Tor
- network will only be untraceable (with respect to Tor's threat
- model) and thus will be at least as likely to be eavesdropped.
+- **Eavesdrop on sensitive data**: The Tor network only prevent the
+ data from being traced (according to Tor's threat model) but does not
+ protect it from eavesdropping.
- **Post-mortem user activity and sensitive data recovery**:
"Normal" operating systems keep a lot of traces about their users'
Internet activities (notably browser cache and cookies) on local
@@ -249,7 +249,7 @@ The user should be able to do all relevant things with easy to use
graphical interfaces. As such it should be presented a solid,
user-friendly desktop environment with all the expected features after
booting: file management, system settings configuration, support
-applications etc..
+applications, etc.

### 2.7.2 Internet applications

@@ -339,8 +339,8 @@ Tools for creating encrypted storage containers are also recommended.
As one of the PELD intent is to permit usage of untrusty computers while
preserving anonymity, measures should be taken against hardware that
might prevent it, such as hardware
-[keyloggers](http://en.wikipedia.org/wiki/Keylogger). Thus a a virtual
-keyboard (used with the mouse) should be available.
+[keyloggers](http://en.wikipedia.org/wiki/Keylogger). Thus a virtual
+keyboard (usable with the mouse) should be available.

### 2.7.8 Entropy

@@ -376,11 +376,11 @@ be developed with i18n/l10n-awareness in mind.

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

-Real-world experience demonstrates the average user quite rarely
-thinks to upgrade his or her PELD copy, and is often pretty happy
+Real-world experience demonstrates that the average user quite rarely
+thinks about upgrading his or her PELD copy, and is often pretty happy
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
@@ -397,7 +397,7 @@ to manually setting up things.

### 2.9.2 Sustainability

-PELD development shoud be a team work rather than a one person work,
+PELD development should be a team work rather than a one person work,
and the deep knowledge of this work should be shared between the team
members. Thus the development infrastructure should be thought and
deployed in order to share this knowledge.
@@ -409,8 +409,8 @@ encouraged. Binary blobs should only be used when no good alternatives
exist, which could be the case with certain hardware drivers or driver
firmwares.

-Similarly, it is recommended that the PELD itself is open-source, and
-that it is well documented to help security analysis by third-parties.
+Similarly, it is recommended for the PELD itself to be open-source, and
+well documented to help security analysis by third-parties.

### 2.9.4 Easy feedback

@@ -422,12 +422,12 @@ pseudonymous) possible way to send this feedback.

# 3 Implementation

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

Critical parts of the config (firewall, polipo and Tor config) are
-based on the well known, trusted Incognito's ones.
+based on the ones from the well known and trusted Incognito.

**NOTICE**: This distribution is provided as-is with no warranty of
fitness for a particular purpose, including total anonymity. Anonymity
@@ -485,11 +485,11 @@ features.
recommended by the above specification)

- [cryptsetup](http://code.google.com/p/cryptsetup/) ensures storage
- encryption using [LUKS](http://en.wikipedia.org/wiki/LUKS)
+ encryption using [LUKS](http://en.wikipedia.org/wiki/LUKS).
- [gnupg](http://gnupg.org) complete and free implementation of the
OpenPGP standard.
- [Torbutton](https://www.torproject.org/torbutton) offers all kind of
- protection against non-HTML anonymity attacks
+ protection against non-HTML anonymity attacks.
- [haveged](http://freshmeat.net/projects/haveged) feeds /dev/random
using HArdware Volatile Entropy Gathering and Expansion algorithm.
- [Vidalia](https://www.torproject.org/projects/vidalia.html.en) is used
@@ -599,7 +599,7 @@ stored there), history is disabled (just in case) and many other things. It is a
not to automatically check for updates of its installed extensions.
Java support is disabled.

-**FIXME**: AFAIK we do not ship cookiesafe. neither has foxyproxy been
+**FIXME**: AFAIK we do not ship cookiesafe. Neither has foxyproxy been
shipped in any release yet.

Iceweasel is shipped with some extensions to help users into managing
@@ -607,7 +607,7 @@ their browsing experience. The
[cookiesafe](https://addons.mozilla.org/fr/firefox/addon/2497/)
extension blocks by default all cookies and provides a button for the
user to accept cookies only on websites where the user needs it. This
-prevents the known leak of browsing informations cookies can lead to.
+prevents the known leak of browsing information cookies can lead to.
The [Adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865/)
extension prevent users from leaving traces of their web browsing by
removing all ads. The [firegpg](http://getfiregpg.org/) plugin allows
--
1.7.2.3