[tor-talk] Tor Browser Bundle w Linux Packaging & TAILS improvements/new distribution

[Chris]

I have a number of questions and requests for possible changes to the Tor
Browser Bundle.


Why is the current Tor Browser Bundle for Linux not available in the Tor
repository?

The reason I am asking is adding the Tor Browser Bundle to the repository
would ensure users have the latest Tor Browser Bundle and eliminate the
risk of a man in the middle attack. Most Tor users do not have the skills
needed to verify the downloads are genuine. On GNU/Linux adding the Tor
Browser Bundle to the repository would ensure the user need not know how
to verify each update as apt already does this. It would also ensures that
ALL security updates get installed ASAP rather than just the base
distribution packages without the user having to take additional steps.

Tails requires users to download a new disc each time an update is
released as well. Like the Tor Browser Bundle this too gives an attacker
more of an opportunity to compromise a Tor user.

Any additional effort / time required from the user is undoubtedly going
to reduce the number of Tor users and increase the dangers.




The second thing I was wondering relates to Tails. Why does Tails need to
be downloaded each time an update is released? If the goal is a read-only
medium there are newer methods to make writeable media read-only without
having to burn a new CD each time and update is released or reload a
distribution.

lathe for instance is a script which creates a read-write update mode
using AUFS and a read-only boot mode.




I've been working on some of these issues for a long time.

One of the issues I've come across is modern media (flash, ssd, etc) has
potential risks (encryption), can be very slow, and is less reliable.

What are the risks of using encryption on flash, ssd, etc? If a user boots
from a read-only (with a secure update mode) flash drive with an encrypted
partition for data how much risk is there given an attacker could
otherwise install a software based keylogger to achieve the same effect?



While I can only assume the Tor Browser Bundle does not have any gaping
security holes there is still a real risk of users leaking. The risk comes
from things like printers, running in the wrong mode (non-Tor mode), etc.
This is not an acceptable risk for many Tor users.




I would like to create a hardened distribution with severe restrictions to
keep users well contained from harming themselves. I believe locking down
the platform is critical as users can't be expected to know or click the
appropriate buttons.


Having worked on some of these issues I realise that a full blown
distribution like Ubuntu requires significant updates. This is a problem
for slower mediums. I would like to create a minimal distribution to
reduce the number of updates a user needs.


Another issue I am trying to solve is the reliability of modern removable
media. Removable media is notoriously unreliable and slow. Especially for
booting off. I'm not sure where the problem lies as I have not found SLC
to be significantly more reliable than MLC. It may be the issue is USB. I
have read something to the effect that when a system loses power you are
more likely to run into data corruption with flash media. While I don't
recall the details it sounded something like the increased write times
means there is a higher chance the data or maybe more data would be in a
buffer somewhere rather than having been written to disk. Thus increasing
the likelihood of corruption.

I think there may be a solution to the above issue. By maintaining two
backup copies of the data a user could restore an uncorrupted copy
"quickly and easily" even if a failure occurs during one of the updates or
backups. Syncing would also be faster than making an entire backup as only
changed files would be replaced/added/deleted. Rsync can be used in
reverse as well so even a failed update could be reverted quicker than
doing a full restore of an entire backup. For those who are not aware
rsync can be used locally without a network connection.

The way I believe this could possibly work in a "quick" manor on slow
media is the following:

apt-get update; apt-get upgrade;
date_of_backup_1=`stat -c %Y /backup1 | sed 's/test.txt//'`
date_of_backup_2=`stat -c %Y /backup2 | sed 's/test.txt//'`

if [ $date_of_backup_1 -gt $date_of_backup_2 ]; then

   rsync -av /root /backup1/*

else
   rsync -av /root /backup1/*
fi

The above would find the oldest backup to sync with. This way if the
system lost power during a sync a restore could be performed from the
other backup. You may need to check that the last syncing of a backup
folder in the above code completed successfully before syncing it again.
Failing to do so may give you a corrupt restore point. I am not completely
sure on this though. It may not be necessary for one reason or another.



locked down /w wifi application available and firefox only (with very
little else)

iptables setup where Internet access is restricted based on the user and
only Tor has access to the Internet; this forces you to go through Tor and
should prevent any leaks

read-only /w read-write update mode to ensure user always has the most
recent security updates without the need to potentially leak encrypted
data to an unencrypted boot partition

apparmor profile applied to firefox to reduce the risk of an unknown
vulnerability

keeping a minimalist design whereby unnecessary and potentially
exploitable components are not included

the inclusion of particular applications that might be needed in a similar
locked down mode (apparmor profile applied)