Fix formatting.

wiki/src/todo/Two-layered_virtualized_system.mdwn

-This is an "unfunded mandate", I'm afraid; I can't work on this. And it's a reasonable
-amount of work.
+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.
+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.
 
 [[wishlist]]