[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #4639 [Tor bundles/installation]: Tails bugs/improvements
#4639: Tails bugs/improvements
--------------------------------------+-------------------------------------
Reporter: cypherpunks | Owner: erinn
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Tor bundles/installation | Version:
Keywords: | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
I tried to use the tails bug reporter but it doesn't work. It fails in two
ways: first, it simply cannot seem to make a proper smtp connection and
thus fails to send any report. Secondly, it doesn't work if you've changed
or removed the .gnupg directory on the file system.
I've decided this is more likely to reach the tails developers than no bug
report at all and so, I'll detail some thoughts here.
Tor should be upgraded to the 0.2.3.x branch to ensure that the seperate
streams feature is activated. This is critical for a system such as tails.
Additionally, the web browser should use a different socks port than the
default Gnome proxy. The web browser should probably randomly genearte a
port (eg: socksport auto) and then a second, probably ranomized, socks
port for the gnome proxy, a third socks port that is commonly known (eg:
9050) and finally, a transport. That should ensure that any identifying
streams are pretty well isolated.
The bug reporter should actually post over http to a hidden service rather
than using smtp if smtp services can't be reached regularly.
Polipo must be removed; it is not supported by anyone for anonymity
reasons and has lots of reliability/security issues. Privoxy is a better
http proxy for most things.
It might make sense to ensure that the browser fully matches the tor
browser, rather than trying to reinvent it.
Local encrypted storage should be better supported. It is currently
possible to use 'cryptsetup luksOpen /dev/foo nameofmapperdevice" but this
is not friendly at all. It would be nice to offer to securely encrypt,
format and use other usb disks. Additionally, persistant storage for the
user's home directory would also be nice but is a much larger issue.
Cryptkeeper is confusing and only appears to work with EncFS.
The lid should not cause a shut down as it results in lost data upon first
discovery of this "feature."
In the future, I suspect it will be useful to replace pdns with unbound.
Jitsi is a possible solution for voip/zrtp/otr that will complement and
perhaps even replace pidgin/libpurple.
The default iptables setup is as follows:
{{{
root@amnesia:/home/amnesia# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere loopback/8
lan all -- anywhere 192.168.0.0/16
lan all -- anywhere 10.0.0.0/8
lan all -- anywhere 172.16.0.0/12
ACCEPT all -- anywhere anywhere owner UID
match debian-tor
ACCEPT all -- anywhere anywhere owner UID
match i2psvc
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain lan (3 references)
target prot opt source destination
REJECT tcp -- anywhere anywhere tcp
dpt:domain reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp
dpt:domain reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere
root@amnesia:/home/amnesia#
root@amnesia:/home/amnesia# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere loopback/8
lan all -- anywhere 192.168.0.0/16
lan all -- anywhere 10.0.0.0/8
lan all -- anywhere 172.16.0.0/12
ACCEPT all -- anywhere anywhere owner UID
match debian-tor
ACCEPT all -- anywhere anywhere owner UID
match i2psvc
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain lan (3 references)
target prot opt source destination
REJECT tcp -- anywhere anywhere tcp
dpt:domain reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp
dpt:domain reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere
root@amnesia:/home/amnesia# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 10.0.0.0/8
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere loopback/9
RETURN all -- anywhere 127.128.0.0/10
RETURN all -- anywhere anywhere owner UID
match debian-tor
RETURN all -- anywhere anywhere owner UID
match i2psvc
REDIRECT tcp -- anywhere 127.192.0.0/10 tcp redir
ports 9040
REDIRECT tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,ACK/SYN redir ports 9040
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
}}}
It seems that the default policy should always be DENY, rather than
ACCEPT.
The default gpg should support the gpg smarts cards and common hardware
(eg: the stuff sold by kernelconcepts.de ).
VPN support should be added to the network-manager setup (dpkg -i network-
manager-openvpn).
The dpkg cache should be populated at some point so that it is useful (eg:
apt-get update)
Adding noscript to disable remote font loading among other things is a
good idea.
Adding sniff joke may be quite useful and it should be an option:
http://www.delirandom.net/sniffjoke/
Disable all firewire kernel modules. This will help fight against
forensics programs that will attempt to suck out memory with the internal
firewire or a cardbus/pcmcia card.
Disable all pcmcia kernel modules; we should try to power off the bus
entirely.
Disable the microphone unless a sound enabled application needs it.
Never automount disks, always prompt a user - still - prompting a user is
very important and will aid users in actually using tails.
We need a buffered ssh client mode - so that ssh sessions are line
oriented and bufered on very slow circuits.
As far as other software goes, Tahoe would be quite useful to include.
Transmission may be useful as well.
The mac addresses for all hardware identifiers should be randomized;
macchanger does it for eth0 and wireless cards - it simply isn't enabled.
They should change each time they change state unless the device is
configured manually to be static.
The kernel: grsec kernel + pax should be a major priority.
Tails should try to check for updates over Tor regularly to ensure that it
hasn't been updated; it should alert the user if there is no update after
a reasonable window of time.
The orca screen reader should have a documented hot key and the website
should explain that tails is accessible with it. I have a nearly-blind
friend who needed this and didn't realize tails included anything of the
sort.
Tails should include a program for usb stick verification - so one can use
one tails install to verify or create others. This should also aid in
detection of backdoored tails installs if someone ever roots someone via a
client side exploit or tampering with the usb disk directly.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4639>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs