A separate $40 ARM box, running some kind of open firewall software (openbsd, m0n0wall, pfsense) that blocks all outgoing traffic that isn't tor is also preferred than trusting say, Virtualbox NAT, which likely leaks host IP to the guest and your VM state to the host.
A bonus to having a dedicated system for whatever secret squirrel things you're doing is it's a physical barrier protecting you from yourself, like when Sabu accidentally logged into IRC in the clear. It's also a good idea to build your own Tails source and hardcode a gigantic password into the startup scripts. This is the "I'm too drunk to be doing this" protection should you ever be faced off your ass and think it's a great idea to go on IRC and taunt the feds or check your sales PMs for the booters and carberp mods you're peddling on not_legaL_hax4sale.ru forums. After 10 tries and failing you'll either pass out or hulk smash the box either way you will not wake up in jail.
I've considered putting pfSense on ARM.
Well, most (all) of the $40 ARM boxes I've seen run the ethernet port off the USB bus... so, an USB ethernet dongle should suffice.
(the USB bandwidth should likely still be faster than your internet connection, but depending on which ARM chip you have, that may become your bottleneck in processing the packets... Beaglebone Black seems like it would suffice though, RPi might be a bottleneck)
Checkout Qubes which was a project that virtualized each app:
Doing that today with Docker containers would be interesting.
[0] This is one of the main reasons why there are efforts to move it to Chromium
The timing is right since OS X Yosemite will include a Hypervisor - so for the first time ever all major operating systems will support it and we have Docker to make it all portable. No more kernel module installation, which is what has always made these type of solutions hard to roll out to consumers and non-techs.
Is that a type 1 hypervisor that can run a linux VM image/container without vbox/parallels/fusion, as if the VM/container was an "app"?
If you look at the architecture diagrams for vbox/vmware etc. you'll see they all have their own implementations of each library to do this on OS X. This is where the performance difference comes from. With Hypervisor.framework and each of the virtualization firms porting their platforms to it, it means this performance difference mostly disappears and the vendors can focus on improving the higher layers.
When Microsoft did this in Windows, the ecosystem exploded. One difference is that Microsoft built and released tools and apps at the higher layers, such as application virtualization with App-V (where they compete with Citrix and VMWare). It doesn't look like Apple will do that, yet - but what it does mean is that someone can port or implement a common virtualization layer on OS X and bring better, cheaper, more accessible and open app virtualization to OS X (with great performance).
It is a pretty big deal with potentially a lot of interesting opportunities and applications. There isn't enough information available about it yet, though (or I simply haven't found it) - someone with more familiarity with the tech and virtualization in general will likely dump info about it and what it would mean when we get more information about it and are closer to 10.10 going gold (the virtualization co's porting their platforms to support 10.10 will likely be an issue).
edit: to add, the good thing about making Hypervisors built into the OS, having an abstraction layer on top of that, and then on the other end having Docker abstract the tech is that suddenly everything becomes portable and developers can focus on the more value add features (since core virtualization tech becomes commoditized)
Apple would need to document the virtual device interfaces so that Linux/BSD in-guest drivers can be developed by the open-source community. Until then, only OSX-on-OSX would work.
Hopefully the Apple hypervisor can be disabled, e.g. if someone wants to run OS X on VMware on Windows on Mac hardware, or OS X on KVM on Linux on Mac hardware.
Their general opinion is that this makes Tails less secure as now you have to trust both the host and the visualization software.
Provided that you trust Tails itself. The expected way to run it is off of a live cd. This way the trusted OS is only ever in ram, and if you use a non-rewritable disk you can also be assured that the Tails disk itself cannot be modified after its creation.
Tails handles the 'only talking to Tor' via iptables. Unless I am mistaken Tails' firewall will not allow clearnet connections.
[0] https://tails.boum.org/doc/advanced_topics/virtualization/in...
The question is, inside the tails itself, should apps like the browser and your mail and chat programs be isolated from each other i.e. placed in "jails", "containers", "zones" or whatever?
Security in depth.
Tails: https://tails.boum.org/
Its an off hand observation I've made before e.g. https://github.com/paulczar/docker-torbrowser/issues/2
Tor should run in a VM or container, and the browser should run in a container that can only talk to the tor, and the only other way out is a dumb screen scraping display for the browser. Make sense?