Slashdot Mirror

Security by isolation is one way to solve that problem. With a hypervisor designed for strong security instead of primarily for conveniece as is usually the case, users can safely allocate their tasks and data to different domains. For instance, 'Work' and 'Personal' could be two domains that have network access, whereas 'Vault' would hold the most sensitive info (like certain keys and passwords) and have no networking. An 'Untrusted' domain is used for most of the general web surfing-- reading articles, watching video streams, etc. On Qubes, there is also a TorVM package that facilitates the creation of anonymous domains.

So, whatever "happens in Vegas stays in Vegas". Qubes even assigns high-risk hardware, like NICs, to their own unprivileged domains.

The nice thing about this setup is that the window manager resides in the privileged domain and both the WM and its graphics stack are isolated from attacks originating in the VM domains. Further, each domain is assigned a border-color when its created so you can always get an idea of what is running in which context by glancing at the desktop. A compromised browser in 'Untrusted', for instance, could put up a window asking for admin access to the privileged domain, but the red border (and [untrusted] marker in the title) would give it away.

Copy/paste and file copy between domains are also protected; they are integrated into the UI so as to require a confirmation step so the privileged domain knows the user really intends to perform the action.

A word of caution: Most hypervisors were made primarily for the convenience of managing multiple systems on a single piece of hardware. If you want strong security around that Windows install you should think about running it in Qubes; version 2 just came out of beta.

The whole mess has a lynchpin (perhaps the only one?)....

Modern computers are vast amalgamations of logic (of varying quality), and we can see only the iceberg tip of the iceberg tip of that content at any given time. Even the experts are left constantly guessing about the doings of all the invisible things inside.

And no, I have no idea how to improve that situation. No matter what you change, you're not going to get any better results.

Start by creating a creating a desktop OS with a hypervisor ingrained into it (all the risky stuff, even graphics and IP stacks are isolated) to reduce the attack surface to a very small area. Then, hopefully, more and more eyeballs and minds will concentrate their attention on the really crucial parts instead of getting PTSD over the whole expanding theatre of apps and services.

Next, turn attention to system firmware (CoreBoot BIOS, and Shuttleworth's initiative to replace ACPI). We're almost half way there now...

Finally, open hardware: CPUs, GPUs and such (we may see mobile devices benefit from this first).

TL;DR: Make the whole logic stack inspect-able and open, and tightly link the security context provided by those components to the privileged part of the GUI.

Also, there are ways to impose strong security on a wide array of existing consumer software. It requires a certain level of hardware features (like IOMMU), but its possible to do even in a somewhat elegant manner.

Qubes systems can keep things like cameras and mics effectively beyond the reach of remote attackers while running Linux and Windows apps.

The core of the system is a pairing of Xen and X11/Linux which isolates the graphics, network and other risky services into less trusted domains. The result is that the trusted X11 can always show you what security context a window or other graphical element represents, even if the untrusted X11 in a VM becomes compromised-- You can't be tricked into thinking a malware element is really a part of the core OS.

And that core OS allows you to (graphically or via CLI) sequester or assign hardware resources to various VMs; You can see at a glance if an untrusted or risky VM still has access to the mic and remove that access with a couple of mouse clicks.

Of course, you still have to trust the hardware and firmware you got from the PC manufacturer.

Securely run Linux or Windows to your hearts' content:
http://qubes-os.org/

Run whatever software you need on Qubes. Even then your system is likely to be more secure than OpenBSD.

Most updates are for security fixes.

OTOH, security by correctness all by itself never prevented resourceful attackers from compiling their own databases of zero-day exploits. Infrequent updates just means the list is somewhat larger. I can't agree with this concept of security.

I've been using Qubes OS to enhance security and though it incorporates Linux it uses a clever Xen configuration instead of SELinux to harden the system. No rules to maintain, just straightforward domains. The upshot is I can even run Windows in seamless mode and still expose my core system to less risk than an OpenBSD system running native apps.

Just to clarify: Hardwire LEDs to the mic and camera. Leaving the LED activation to firmware is asking for an exploit.

These are good ideas. However they are kind of obvious and their total absence on phones and PCs shows that major IT vendors don't have designers involved in security at all. That vacuum and lack of involvement is astonishing.

BTW, if you want some of those other features in a PC, check out Qubes OS. Its a Xen-based desktop with great virtualization and boot protection features; its (much) more secure than other VM environments and will even automatically isolate vulnerable hardware like network cards from the core OS.

It was designed assuming X11 (and Linux itself) had big security holes to begin with.

In fact, after acclimating to the Qubes desktop architecture the whole monolithic kernel + X server arrangement looks like a raft full of holes waiting to exploited. Both the X11 layer *and* the Linux kernel need to be demoted to providing features only, not relied upon for overall system security.

See http://qubes-os.org/trac/wiki/QubesArchitecture

Computers can be operated such that all networking components starting at the NIC and ending at the (entire) remote system are untrusted. In an OS like Qubes, the NIC and IP stack are operated in their own untrusted VM running from a read-only template.

It works great!

Then, of course, there are the tools you can use to enhance privacy and trust: Tor and I2P use onion routing and use addresses that are verified with crypto. Where I2P improves over Tor is in the former's abilities as a general purpose transport, and its P2P spin (lack of centralization) on onion routing.

When the privacy tools are not application-specific, there is better potential for consistent utilization and for thwarting attacks.

Although it may be good enough for stopping Twitter, the trouble with Sandboxie is that it still relies on Windows, which cannot be trusted for other reasons. IMO, if you're going to the trouble of sandboxing everything anyway, you might as well just skip straight to Qubes OS.

Or you can use this ...which I am typing in at this moment.

In those "best linux distros" I just discovered Qubes OS which achieves security (and privacy) through strong isolation.

See what kind of activities can be isolated, in a picture.

I think they got it right.

Not very portable: one need to run it on bare metal (along with 4GB minimum), nomads will bring along their laptop, at least (also: secure boot optional).

This is interesting and particularly relevant because it is the exact opposite to Ubuntu's theos. In ubuntu things you do on your local machine get propagated to the web. In Qubes OS, if I understand it correctly, things you do on your machine in one area, sites you visit in another (e.g. porn), and sites in a third (e.g. banking) will all be completely isolated from each other.

In those "best linux distros" I just discovered Qubes OS which achieves security (and privacy) through strong isolation.

See what kind of activities can be isolated, in a picture.

I think they got it right.

Not very portable: one need to run it on bare metal (along with 4GB minimum), nomads will bring along their laptop, at least (also: secure boot optional).

Hypervisor desktop employing some of the more powerful hardware VM features found in newer processors to create a substantially more secure environment.

Yes, when I saw this I thought that this was a reason to make motherboard IOMMUs a security feature. Also, the DMA destination memory pages should not have the executable bit turned on. Recent generations of Intel/AMD CPUs have provided the ability to turn that bit off.

Qubes implements this security feature. Pretty much every peripheral is isolated from the core system / hypervisor via the IOMMU, and it even runs X11 and the network stack in separate VMs. It is probably the only Linux (or Linux-ish) system to secure these known vulnerabilities.

You can also do the same for other hardware devices (assign hardware to certain VMs) using the GUI, along with a lot of other really nice point-and-click features. Security context is reflected in the GUI using window colors.

A final note: Multi-user is actually deprecated and security is all based on domains. The system is designed to function strictly as a single-user PC (in fact, the focus is more toward laptops), which I find refreshing. If you need multiuser you can always create an HVM to run non-native OSes.

Addressing the non-flesh-and-blood part of your question, two pieces of software could make a big difference if enough people adopt them: The I2P darknet (which uses stronger encryption than Tor, among other advantages), and Qubes OS which provides a large enhancement of security over what you would find in even the most hardened Linux system.

These two things stymie both the "legal" spying that was setup within ISPs and services like Google, and the ability of others to break into your systems and steal/infect stuff.

http://qubes-os.org/trac/wiki/QubesArchitecture

Compartmentalize the high-risk parts of the OS (like network and X11) into separate VMs that each get access to only the hardware they need via the IOMMU.

Then you make it easy to use the hypervisor to graphically create separate color-coded domains: personal info, banking etc. go into one domain; work-related stuff into another; general browsing and other higher-risk stuff go into a third. The app windows from each of these "app domains" appears with the corresponding border color.

If your network stack becomes compromised, the infection goes away when you reset the netVM or reboot the system. Same goes for the display, and for the disposable app VMs. Theoretically, nothing should be able to touch your Dom0 hypervisor or your other domains... or at least that task becomes extremely difficult for an attacker.

You need certain late-model systems to take advantage of these security features, though.

http://qubes-os.org/trac/wiki/QubesArchitecture

Compartmentalize the high-risk parts of the OS (like network and X11) into separate VMs that each get access to only the hardware they need via the IOMMU.

Then you make it easy to use the hypervisor to graphically create separate color-coded domains: personal info, banking etc. go into one domain; work-related stuff into another; general browsing and other higher-risk stuff go into a third. The app windows from each of these "app domains" appears with the corresponding border color.

If your network stack becomes compromised, the infection goes away when you reset the netVM or reboot the system. Same goes for the display, and for the disposable app VMs. Theoretically, nothing should be able to touch your Dom0 hypervisor or your other domains... or at least that task becomes extremely difficult for an attacker.

You need certain late-model systems to take advantage of these security features, though.

5. Protect against remote exploits with an OS like Qubes. Use its TorVM and DisposableVM features to isolate different communication domains from each other. (Certain late-model hardware configurations are best used with Qubes.)

6. Go one better than Tor and use I2P. It uses routing that is more decentralized than Tor, and since everyone shares routing bandwith by default there is bandwidth to handle virtually all kinds of traffic... even bulk transfers and bittorrent. Security is also enhanced by having more users route traffic, and by communicating only with other I2P users by default. I2P have so far been successfully testing a distributed email system (I2P-Bote) which is far less vulnerable to attack than what you find on Tor (e.g. TorMail).

Or you could just add the TorVM package to QubesOS where all apps are transparently virtualized.

TFA is correct that there isn't anything to patch per se. However, it's possible to mitigate the effects of this by using multiple completely isolated browser sessions for different purposes. Your banking VM should always be used for banking, nothing else. Clear cookies and browser history at the end of the session. All that while other VMs should be used for their own specific purposes with their own security configuration.

This is very well implemented in Qubes OS but can also be implemented via regular VMs. The guys at Bromium have also an interesting approach to this issue via microvirtualization using hardware.

Net/net, the important thing is to make sure that whatever the attacker can get, it's irrelevant in the big picture of things.

something like a pure debian with tor and privoxy in it, which starts a browser, and load virtualbox/vmware modules. Then you just boot it and switch to "seamless mode" and get nothing but a free floating browser window. if you close it, you will be asked if you want to restart the browser or shutdown the vm.

Qubes OS has those features. The Tor VM just has to be installed as an additional step.

http://qubes-os.org/

This system lets you easily launch browsers (or other apps) within different security contexts. Security is enforced by a hardened Xen hypervisor, and even some system services like graphics and net stack that are considered high-risk are also run within their own VMs. You can selectively grant a VM access to particular hardware if your system supports VT-d or IOMMU. A special variation on copy-and-paste lets you perform those functions between VMs without the risk of a compromised program trying to sniff your clipboard.

There are App VMs which appear on the desktop as normal windows except for their context frame color, and HVMs which can run a whole different OS like Windows, and Disposable VMs that retain no state between launches.

There is also special VM support for Tor that can be installed.

And no one is claiming it is perfect, BTW. But a candidate "most secure browser" should ideally be running on a system such as Qubes.

Even if I have nothing to hide, for me it's the principle of things. I moved my email from Gmail to Neomailbox.net who is based in Switzerland. They are very serious about security and encryption. I also trained my family members in other countries to use Thunderbird with Enigmail/GPG (not really that difficult once you set it up correctly). I also have accounts in Tormail (Tor only) and other non-US servers. I still haven't found a reliable XMPP server that I can easily setup with OTR, although I'm looking at Cryptocat.

For browsing and other secure applications, I'm using several things: 1) A good VPN connection at all times (I use WiTopia), 2) Whonix on my Mac for secure browsing, Bitcoin and other applications. It's great due to stream separation. 3) On my main laptop, I dumped Ubuntu for Qubes OS that works great.

Overall, I try to support I2P and the [legit] Onion sites whenever possible. I donate Bitcoin to all efforts towards open security and privacy.

To have the possiblity of secure communications, I suggest buying a recently manufactured PC with VTx and VTd/IOMMU capabilities and get used to running a minimally exploitable OS on it.

For portable devices, I recommend something that can have all the firmware flashed to something like Android or Firefox OS, has a removable battery, and no cellular radio. Also, re-flash on a regular basis.

http://qubes-os.org/

It gives you hardware-enforced security for your desktop.

The browser is a rather complex beast and there is probably no way that the application itself can ensure system integrity... at least with any consistency.

Some of us are migrating our online activities to Qubes OS which is a desktop distro (I know...) that allows you to create App VM domains for things like "personal", "work", "unsafe", etc. and also a "disposable" one that gets reset on exit. Each domain of apps is displayed in window borders that have an associated color.

Taking it further, some of the commonly-attacked system components like the network stack are virtualized as well.

Qubes employs VT-x and VT-d/IOMMU hardware to allow you to operate different types of peripherals (like bluetooth) without incurring all of the risk they normally carry. Even device drivers are paravirtualized! So the attack surface that can be used against the core system (or any other domains in the system) is kept to a bare minimum.

An added benefit of this approach is that user activities are tracked somewhat less than normal (especially if you use disposable VMs).

then one could still consider the device to be a security risk. Even Linux tends to use many vendor-supplied firmwares.

Operating the devices under Qubes OS would help greatly in reducing the risk: It can use IOMMU (if present) to operate questionable hardware and drivers within VMs and even has a GUI for managing this.

1) Build a conventionally-designed desktop OS (perhaps from Linux or BSD components): It would have an SDK with a clearly defined but rich set of interfaces/libraries making it easy to write programs that run on just about any installation of that OS without getting tangled in a lot of fuss. To that end, apps would be fully contained in each of their own app directories (like GoboLinux and OSX) and there would be a default IDE along the lines of Xcode and Visual Studio. Most apps need only check the OS version to satisfy their dependencies.

2) Restore mouse cursor feedback to Qubes AppVMs... http://www.qubes-os.org/

3) Add desktop sharing capability to X11 or the freeNX protocol (not sure now, but this still wasn't done a couple years ago when I last checked). Currenty X11 systems can only share a screen between two or more people by inefficiently tossing bitmaps around (using VNC). Windows and OSX have had the abstraction layers to do this efficiently for about a decade.

4) Write a great CAD program to compare with AutoCAD (though this may be tough even for a PhD level project).

Oops... too many suggestions.

Good luck with whatever you choose!

This looks interesting: http://qubes-os.org/

Its based on Linux and uses some newer virtualization features in CPUs to increase system security, and is able to enforce (and represent) security context in the GUI. They even tout a feature (anti-Evil Maid) that foils attackers with physical access (though they say nothing is perfect).

They say that garden variety VMs like VirtualBox and VMware increase security to some extent, but that they were mainly designed to make computing more convenient and efficient (i.e. they are not the most secure usage of virtualization technology). Qubes seems to have the goal of making high security convenient, so I will surely be trying this out soon.

I can hardly believe that, so far, nobody mentioned Qubes OS.

In the theoretical sense, security is possible. It's just very hard. Especially if you want to spend your time doing something other than building a secure computer system.

In practice, most people live with a reasonably amount of security by installing a reasonable alternate OS such as Debian, not installing unnecessary software such as the Java plugin, and regularly installing security updates.

But if you really want security, what you should be doing is isolating, isolating, isolating. If a program has no business using a resource, then it should not be possible for it to access that resource. Qubes is one attempt to do this while preserving application compatibility, by having applications and services isolated to their own virtual machines. Even the network card drivers are in separate virtual machines.

For maximum security with Qubes, you really need a processor with support for VT-d, such as a selected subset of Nehalem and better processors, but the AppVM security mechanism at least should work.

You should look into Qubes OS.

http://qubes-os.org/

It uses a minimal hypervisor and the linux kernel to enforce process separation. Haven't looked into whether it's actually usable, but if you want security uber alles, it seems like the way to go.

Or you could stick Firefox in a chroot and use HTTPS Everywhere. And y'know, NoScript and Adblock Plus and Ghostery -- but I presume you're using those already. SSL certs aren't necessarily handled by the browser anyway, but I think what you want there is the also-extant OCSP. Or if you wanted to extend the chroot concept to your entire OS, you can have that too.

Why do you need desktop links again? I'm having a failure of imagination as to how that might actually improve anything.

bee-tee-dub, you should keep in mind that Security and Usability are usually at odds with each other. We already have the technological solutions at hand, if you're not already using them, perhaps there's a reason why.

Note: We don't recommend installing Qubes in a virtual machine!

No, I'm not going to say something snarky like "you should have read the system requirements." or some demeaing bullshit that's all to common on Slashdot that also gets mod'ed up.

if I had a machine available I would have done the same thing - hey, that's what we do! jump in, try it out, and have fun

I'm not sure, but it seems to have a Fedora base. Talks about KDE a lot. See also: http://wiki.qubes-os.org/trac/wiki/InstallNvidiaDriver

This was found by Rafal Wojtczuk who is a co-author of Qubes OS that tries to bring strong security to the desktop. http://qubes-os.org/Home.html http://groups.google.com/group/qubes-devel/browse_thread/thread/248a59a1050fe9d4

Someone enlighten me, why Wayland?

There are many reasons to adopt Wayland.
The reason I have been following Wayland so closely is to ditch X.
X is the Linux Desktop's largest security hole.

::further reading::

Qubes OS anyone?

http://qubes-os.org/Home.html - possible android version? Use a MiniOS kernel (xen team homebrew) - just for auth, hardware lock access to the smartcard to just that domain - and your golden.

Joanna Rutkowka's Qubes. Security is the future. http://qubes-os.org/trac/wiki

I'm hoping to see something like Joanna Rutkowska's Qubes come to fruition - http://qubes-os.org/Architecture.html. It allows the creation of lightweight VMs to run a specific app.
Much more useful, if it's as quick as she claims. It's Linux-based for the moment.

Take a look here. http://qubes-os.org/Home.html