Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
tails
tails
Commits
24b42750
Commit
24b42750
authored
Feb 22, 2011
by
T(A)ILS developers
Browse files
Fix formatting.
parent
a956f94f
Changes
1
Hide whitespace changes
Inline
Side-by-side
wiki/src/todo/Two-layered_virtualized_system.mdwn
View file @
24b42750
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]]
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment