Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Umm... just WMVs? (Score 1) 150

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.

Comment Intel a chronic cheater on benchmarks (Score 1) 217

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.

Comment Re:Amiga did this back in the 80's! (Score 1) 47

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.

Comment Re:and it does not use systemD (Score 1) 47

"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 -

Comment Re:sounds like Mac OS X app resources (Score 1) 47

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).

Comment Re:Ironic (Score 1) 28

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).

Comment Re:not nearly good enough. (Score 1) 39

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.

Slashdot Top Deals

Take an astronaut to launch.