Commit c60ce88b authored by T(A)ILS developers's avatar T(A)ILS developers
Browse files

Merge branch 'master' of ssh://webmasters.boum.org/~/wiki

parents 4e6169c8 79ec2b7d
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2011-02-21 05:42-0800\n"
"POT-Creation-Date: 2011-02-22 11:44-0800\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -80,8 +80,8 @@ msgstr ""
#. type: Bullet: '* '
msgid ""
"You also want to install `po4a` so that ikiwiki will build smoothly in all "
"languages."
"You also want to install `po4a` and `perlmagick` so that ikiwiki will build "
"smoothly in all languages, and include the needed images."
msgstr ""
#. type: Title =
......
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2011-02-21 05:42-0800\n"
"POT-Creation-Date: 2011-02-22 11:44-0800\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -112,8 +112,8 @@ msgstr ""
#. type: Bullet: '* '
msgid ""
"You also want to install `po4a` so that ikiwiki will build smoothly in all "
"languages."
"You also want to install `po4a` and `perlmagick` so that ikiwiki will build "
"smoothly in all languages, and include the needed images."
msgstr ""
#. type: Title =
......
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2011-02-21 05:42-0800\n"
"POT-Creation-Date: 2011-02-22 11:44-0800\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -80,8 +80,8 @@ msgstr ""
#. type: Bullet: '* '
msgid ""
"You also want to install `po4a` so that ikiwiki will build smoothly in all "
"languages."
"You also want to install `po4a` and `perlmagick` so that ikiwiki will build "
"smoothly in all languages, and include the needed images."
msgstr ""
#. type: Title =
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2011-02-21 05:42-0800\n"
"POT-Creation-Date: 2011-02-22 11:44-0800\n"
"PO-Revision-Date: 2010-11-01 18:50+0100\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -103,8 +103,8 @@ msgstr ""
#. type: Bullet: '* '
msgid ""
"You also want to install `po4a` so that ikiwiki will build smoothly in all "
"languages."
"You also want to install `po4a` and `perlmagick` so that ikiwiki will build "
"smoothly in all languages, and include the needed images."
msgstr ""
#. type: Title =
......
......@@ -28,8 +28,8 @@ Dependencies
[wishlist item](http://ikiwiki.info/todo/mirrorlist_with_per-mirror_usedirs_settings/)
to get the custom ikiwiki branch that has the needed code. It is
not critical to do so.
* You also want to install `po4a` so that ikiwiki will build smoothly in
all languages.
* You also want to install `po4a` and `perlmagick` so that ikiwiki
will build smoothly in all languages, and include the needed images.
Build process
=============
......
This is an "unfunded mandate", I'm afraid; I can't work on this. And it's a reasonable
amount of work.
[[!toc levels=2]]
It is, however, based on a long, long acquaintance
with the problem space. This is something I was thinking about doing for the
old Zero-Knowledge Freedom system back in 2000, because of bugs we kept finding
and attacks we kept coming up with.
This is an "unfunded mandate", I'm afraid; I can't work on this. And
it's a reasonable amount of work.
It is, however, based on a long, long acquaintance with the problem
space. This is something I was thinking about doing for the old
Zero-Knowledge Freedom system back in 2000, because of bugs we kept
finding and attacks we kept coming up with.
If you want to discuss this, I'm jbash at-sign velvet period com .
##The Problem
# The Problem
A lot of code runs inside amnesia: big programs like Web browsers,
Pidgin (with plugins), OpenOffice (eek!), etc. Each of those programs will
(not may, but definitely will) have security holes that will leak the real IP
address of the machine, and possibly other information.
They will also have holes that will allow remote sites to execute arbitrary
code sent back through Tor connections. This code can then grovel
through /sys, /proc, and wherever else, and extract an endless number of
hardware serial numbers, MAC addresses, unique combinations of configuration
elements, and so forth, any of which may identify the user's machine
to the remote attacker. That's especially true if the remote attacker is in a
position to ask a manufacturer who bought a given piece of hardware,
but that's not the only way of using the information.
Pidgin (with plugins), OpenOffice (eek!), etc. Each of those programs
will (not may, but definitely will) have security holes that will leak
the real IP address of the machine, and possibly other information.
They will also have holes that will allow remote sites to execute
arbitrary code sent back through Tor connections. This code can then
grovel through /sys, /proc, and wherever else, and extract an endless
number of hardware serial numbers, MAC addresses, unique combinations
of configuration elements, and so forth, any of which may identify the
user's machine to the remote attacker. That's especially true if the
remote attacker is in a position to ask a manufacturer who bought a
given piece of hardware, but that's not the only way of using the
information.
Exploit code can also try to disable or circumvent the local firewall
and send traffic that doesn't go through Tor. There are a lot of tricks for doing
this, especially because all it takes is one packet, sent from any
part of the system, to a chosen destination without going through
Tor.
##The Partial Solution
Split amnesia into two parts: an outer, host part running on the user's real
hardware, and an inner, guest part running in a virtual machine. Keep all
information about the real identity of the user or the user's computer in
the outer machine. Keep all applications in the inner machine. Mount
any storage meant to be writable by the inner machine as a virtual
device provided by the outer machine. If you encrypt the writable
storage, the crypto should probably run on the outer machine, so that the inner
machine doesn't need to have access to the key.
Ship the entire inner virtual machine image as part of amnesia, so that
each instance is identical in every way that can be seen from inside...
so, for example, the inner machine might always have MAC address
00:11:22:33:44:55 , and IP address 10.1.2.3.
and send traffic that doesn't go through Tor. There are a lot of
tricks for doing this, especially because all it takes is one packet,
sent from any part of the system, to a chosen destination without
going through Tor.
# The Partial Solution
Split amnesia into two parts: an outer, host part running on the
user's real hardware, and an inner, guest part running in a virtual
machine. Keep all information about the real identity of the user or
the user's computer in the outer machine. Keep all applications in the
inner machine. Mount any storage meant to be writable by the inner
machine as a virtual device provided by the outer machine. If you
encrypt the writable storage, the crypto should probably run on the
outer machine, so that the inner machine doesn't need to have access
to the key.
Ship the entire inner virtual machine image as part of amnesia, so
that each instance is identical in every way that can be seen from
inside... so, for example, the inner machine might always have MAC
address 00:11:22:33:44:55 , and IP address 10.1.2.3.
Make sure that the face presented to the inner machine by the outer
machine is also always the same; for example, the inner machine might
always see the outer machine as a default router at MAC
00:55:44:33:22:11, with an IP address of 10.1.2.1. You don't want
any information about the outer machine to leak to the inner machine
via, say, ARP, or DHCP, or any weird management protocol.
00:55:44:33:22:11, with an IP address of 10.1.2.1. You don't want any
information about the outer machine to leak to the inner machine via,
say, ARP, or DHCP, or any weird management protocol.
The outer machine should run the hypervisor, and all code that has to
talk to the "real" network: link-layer supplicants, DHCP client, NTP,
Tor itself. The inner machine should be able to connect only to the Tor
port of the outer machine. The outer machine should have a firewall
configured such that no traffic can ever be relayed directly from the
inner machine to the network. The only way the inner machine can talk to
anything should be through Tor.
This includes traffic to the local LAN, BTW; local LAN commmunication is a huge
security hole, because it's usually easy to get a machine on the local LAN
to send something to the outside for you, identifying the user in the
process.
The inner machine can and almost certainly should be aware that it's talking
through a SOCKS proxy. Trying to be transparent using firewall diversion
hacks will probably break more things than it fixes.
##Remaining Holes
This change reduces the attack surface a lot, but it's still subject to
attack through bugs in Tor, bugs in the hypervisor, bugs in the outer
machine's IP stack, and bugs in the kernel on the outer machine. Oh,
and bugs in the hardware. The
good news is that you have to crack the applications before you can attack
any of those, so there's some defense in depth; it takes knowledge of
two unpatched bugs, instead of just one, to actually nail the user.
The hypervisor used should be as simple as possible. I don't know about
Virtualbox, but VMWare is a nightmare of complexity and guaranteed to
be full of holes. qemu might be a better bet than either, simply because
it's not so loaded down with features, and does fewer things to "help"
you (and potentially leak information).
## Interacting With User Virtualization
Tor itself. The inner machine should be able to connect only to the
Tor port of the outer machine. The outer machine should have a
firewall configured such that no traffic can ever be relayed directly
from the inner machine to the network. The only way the inner machine
can talk to anything should be through Tor.
This includes traffic to the local LAN, BTW; local LAN commmunication
is a huge security hole, because it's usually easy to get a machine on
the local LAN to send something to the outside for you, identifying
the user in the process.
The inner machine can and almost certainly should be aware that it's
talking through a SOCKS proxy. Trying to be transparent using firewall
diversion hacks will probably break more things than it fixes.
# Remaining Holes
This change reduces the attack surface a lot, but it's still subject
to attack through bugs in Tor, bugs in the hypervisor, bugs in the
outer machine's IP stack, and bugs in the kernel on the outer machine.
Oh, and bugs in the hardware. The good news is that you have to crack
the applications before you can attack any of those, so there's some
defense in depth; it takes knowledge of two unpatched bugs, instead of
just one, to actually nail the user.
The hypervisor used should be as simple as possible. I don't know
about Virtualbox, but VMWare is a nightmare of complexity and
guaranteed to be full of holes. qemu might be a better bet than
either, simply because it's not so loaded down with features, and does
fewer things to "help" you (and potentially leak information).
# Interacting With User Virtualization
It's presumably an important use case to have users run amnesia inside
of virtual machines that are part of the users' regular enviroments. As
far as I know, no X86 virtualization system will let you nest VMs, so
that implies that you can't do this trick when amnesia is run under the
user's hypervisor. Probably the "best" solution would be to reconfigure
the user's environment to provide the necessary services to the amnesia
internal virtual machine, but that's also probably an unsupportable release
nightmare. The alternative would be to fall back to something like
the way things work now, with Tor running inside the virtual machine...
but to warn the user that she was operating with degraded security.
of virtual machines that are part of the users' regular enviroments.
As far as I know, no X86 virtualization system will let you nest VMs,
so that implies that you can't do this trick when amnesia is run under
the user's hypervisor. Probably the "best" solution would be to
reconfigure the user's environment to provide the necessary services
to the amnesia internal virtual machine, but that's also probably an
unsupportable release nightmare. The alternative would be to fall back
to something like the way things work now, with Tor running inside the
virtual machine... but to warn the user that she was operating with
degraded security.
# Inspiration
* [A Tor Virtual Machine Design and
Implementation](https://svn.torproject.org/svn/torvm/trunk/doc/design.html),
aka TorVM design document
* JanusVM
##A promising, alternative solution: Qubes
......
This diff is collapsed.
[[wishlist]]
Please update Torbutton to 1.2.3 or later. There are very annoying
bugs in previous versions, some of which have security implications.
The current version, 1.2.1, is a whole year old.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment