Running code isolated by a bare-metal VMM like Xen is much better than running it in bare-metal Linux from a security standpoint. Comparing Linux and Xen vulns, there is a stark contrast. And that is even before one subtracts DOS and vulns in superfluous Qemu components.
So, yes, VM breakout "is a thing", but mainly on hypervisors that were designed to run on top of a complex OS and dedicated foremost to administrative convenience.
Tails has the drawback that its vulnerable to DMA attacks, i.e. if your NIC or USB controller is compromised, then it can do anything and even has a chance to install malware in the BIOS, drive firmware, etc. Qubes uses the IOMMU to isolate risky hardware, so this type of attack is prevented.
And they were found guilty of bribing vendors not to use AMD chips.
Intel partners with software companies, and gets them to use their compiler that switches off optimizations on non-Intel CPUs 'just because...' regardless of capabilities.
And now they're pushing Trump's deregulation pro-pollution agenda. That's the last straw from these crooked people.
install Linux. Heck, in a VM if you're lazy.
In a VM if you're smart.... https://www.qubes-os.org/
Better still is Whonix (VM isolation for both Tor and Torbrowser). TAILS may have a fancy configuration to attempt leak prevention, but privilege escalation attacks are a dime a dozen on Linux.
By the time you get to AmigaOS 3.x (probably 2.x), an app author could choose to have their non-OS dependencies all relative to the app dir. The only exception was something that required a new hardware driver. Of course, there were a few large libraries (one add-on widget set, as I recall) that developers wanted to treat as a common resource.
The Amiga did "do that" to an extent, but the built-in OS functions were too sparse to avoid the developer interest in shared, third-party libraries and runtimes.
Ubuntu also has something similar now: http://snapcraft.io/docs/core/...
"Monolithic apps" is nothing but a formal acknowledgement that the OS stops providing APIs at some boundary. This helps keep both the OS and the app(s) well-defined. What an app needs beyond that point should be supplied by the app's author. Windows follows this model to a certain extent as well as OS X.
OTOH, Linux distros have taken the management model for OSs internals and extended it into applications. This reduces the apps' integrity as a separate (if dependant) thing.
OS maintainers should not be meddling in app packaging to the extent they do on regular Linux distros. It means that every app must be chewed-up into little pieces and sprayed around different places in the filesystem. It means your app will be paired with library revisions it was never tested with, not just for traditional OS functions but also for a lot of the features that make the app(s) interesting. It means app developers have to track the developments in 1,000 different projects instead of worrying about Apple/Microsoft + the 4 extra libraries added to their app. This is one of the reasons Linux repels app developers, and people more intelligent than me, like Mark Shuttleworth, have complained about it for a long time.
Here is Ubuntu's solution - https://www.ubuntu.com/desktop...
Which means its ability to handle system events and manage power must be sh!t. I remember the first time I booted an OS X system that had LaunchD; It only took a few minutes to know it was better. Had the same experience when Ubuntu got Upstart.
I think both Qubes and Gobo are interesting, but to me Gobo's promise was about making the system more sane and manageable to both app developers and their users.
OTOH, this filesystem virtualization could be a nice compliment to AppArmor and maybe enhance security. The underlying problem remains, however: Relying on security features provided by a huge monolithic kernel is always a risky proposition. At the end of the day, I'll organize my computing by threat model (Qubes domains) instead of by convenience (OS X, Gobo).
Probably because security (not just privacy) conscious Tor users were already resorting to platforms like Whonix, a VM that runs on Qubes OS. Think of it like "sandbox++".
The problem is that Qubes can be very finnicky about the hardware it runs on. It prefers to have equipment like an IOMMU, and if your game-o-tron "rig" has all that nice hardware in spades, the firmware will probably fubar it. If you have a Mac, USB hardware cannot be effectively isolated. Qubes usually travels "PC business class" for those reasons: Thinkpads, etc.
So offering garden-variety isolation (monolithic kernel sandboxing) is an accessible way to increase the security level of a privacy platform like Tor. Just don't expect that sandbox to be as strong as what Qubes offers (bare-metal hypervisor isolation).
Wifi equipment has started down a road of anonymization. Linux users have been tinkering with macchanger for a while (though not effectively enough to stop the native MAC address from popping up now and then). Apple made the first big splash when they made MAC randomization standard for scanning mode; Android copied that. Microsoft followed suit with a MAC randomization in more modes. Then the Linux folks finally did it right by building MAC randomization features into Network Manager. The idea, of course, is to keep the original MAC address suppressed.
Stay tuned for more.
Maybe the increase in competition will be a good thing.
On the negative side, hardware (esp. DRAM) is becoming a security nightmare, and I don't think Kaspersky OS is going to mitigate that any better than the others.
Anyone trusting a secure drop system that involved Kevin Poulsen in its development, should look at what happened to Chelsea Manning.
Anyone can make an omelet with eggs. The trick is to make one with none.