[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Subgraph vs Qubes OS: Subgraph gets KO'ed & Win10 Data Slurping


#1

https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/

Summary:

Basically, the isolation provided by Qubes OS (when used properly) beats on Subgraph OS like they are a red headed step-child. Further, Qubes is only affected by around 10% of all Xen exploits found on the XSA list.

Right now, Subgraph OS can be pwned easily via Nautilus and malicious .desktop files, or if you run applications that don’t run in one of the many app (Oz) sandboxes. Malicious malware can easily bypass Subgraph’s application firewall too.

Subgraph’s only main advantage is grsecurity by default. But consider this:

  • grsec templates are coming to Qubes (with Debian templates already available and working);
  • Whonix is already integrated into Qubes;
  • Disposable VMs are available in Qubes for dangerous links/docs/files;
  • Disposable Whonix-Workstation VMs are available in Qubes (with multiple disposable VMs available in Qubes 4);
  • Qubes is not in alpha status;
  • Subgraph can’t isolate the network stack like Qubes OS or deal with bad USB exploits; and
  • Subgraph templates are theoretically possible in Qubes.

There simply is no comparison for the discerning paranoid user - assume future compromise and isolate everything in a fine grained manner with Qubes.

Have a Win 10 Creators Update Data Slurpee

In the Creators Update, aka Windows 10 version 1703, all this information will be collected in Basic mode. A lot of it is to help Microsofties pinpoint the cause of crashes and potential new malware infections, although it includes things like logs of you giving applications administrator privileges via the UAC, battery life readings, firmware version details, details of your hardware down to the color and serial number of the machine, which cell network you’re using, and so on.

Then there’s the information collected in Full mode, which includes everything in Basic plus your user settings and preferences, your browser choice, lists of your peripherals, the apps you use to edit and view images and videos, how long you use the mouse and keyboard, all the applications you’ve ever installed, URLs to videos you’ve watched that triggered an error, URLs to music that triggered an error, time spent reading ebooks, text typed in a Microsoft web browser’s address and search bar, URLs visited, visited webpage titles, the words you’ve spoken to Cortana or had translated to text by the system, your ink strokes, and more.

Thoughts:

Why are there only 25,000 people using Qubes world-wide, while billions of people are paying to use Windows XP/Vista/7/8/10 to be profiled up the wazoo? It boggles the mind.

Insofar as the “But I need Windows for X, Y and Z” argument - that’s fine, run it in a Windows VM in Qubes. Better yet, set the NetVM to “none” post-update so that it can’t phone home everything you are doing.


#2

Thank you for sharing relevant on-topic news!

Could be many reasons.

  • Windows gets preinstalled.
  • Works a lot better due to hardware vendors cooperating exclusive with Microsoft.
  • First mover and networking effects.
  • Barely anyone knows there are choices, let alone their differences.
  • Usability issues.
  • Lack of time / interest / laziness.

#3

Nice. Lets include the summary and link to Micah’s article on the SubgraphOS comparison page.


#4

Will do.

Note that is my summary of identified issues, not Micah’s. I don’t think “beats on Subgraph OS like they are a red headed step-child” is considered acceptable language and polite in the computer research field.

:smile:

BTW they have now fixed the .desktop file issue.


#5

I don’t think Micah beats on them. Besides the .desktop file thing, he pointed out core design flaws in Subgraph’s approach to security in general. For security, virtualization (though which hypervisor is another matter) trumps containers. Virtualization has decades of theory behind it and while not perfect is the best we have short of disposable hardware. Though theoretically both VMs and containers can be combined for defense in depth. Things we already knew but the fact that it comes from a big name in the privacy community upset them more than anything we could have written.

Developers’ attitudes to bug fixing and the way they interact with a community are important indicators of a project’s health though its not directly related to code. Non cooperative and protectionist distros like them and Ubuntu are considered obstacles routed around by the community which come up with better alternatives that are then widely deployed anyway. The difference is they lost the chance to be the source of this contribution. The market-share of SecureOSs is so small that fighting over scraps is missing the point of libre software and makes them look pathetic.

Its essential to be honest about a system’s security limitations especially if you are advertising it as the go-to OS for people who could be risking their lives and may not be technically knowledgeable enough to figure out your claims themselves. Since Subgraph refuse to do this (or do so for some things after we point them out) they label any attempt of others, as an attack on their project. There is no place for PR in academic and technical circles concerned with facts.


#6

All valid points.

If they really cared about security, they’d have built the Subgraph OS template for Qubes already, since the technical obstacles don’t seem that large (can be run in a HVM; subgraph OS is based on Debian etc).

Well, at least according to the maestro marmarek:

I think the steps include:

  • getting SGOS kernel (especially GrSec) running in Qubes VM - IIUC this requires running it as HVM
  • checking SGOS compatibility with Qubes GUI agent (if SGOS uses standard Xorg server as the final chain in GUI, it shouldn’t be a problem, at least in theory)
  • building actual template (build scripts etc)
  • minor adjustments, like ensuring application menu points to the right executables

Is it possible to (easily) convert standard Debian testing installation into SGOS? In that case, building the template can be just an addon to building standard Debian template (the same way as Whonix template is built). Links:
[https://www.qubes-os.org/doc/qubes-builder/]
[https://www.qubes-os.org/doc/building-non-fedora-template/]
[https://github.com/qubesos/qubes-builder-debian]
[https://github.com/Whonix/qubes-template-whonix]

As for testing GUI agent - all the relevant packages are available in http://deb.qubes-os.org/r3.1/ (signing key) installing qubes-core-agent and qubes-gui-agent should take care of most of the things. But keep in mind those packages are quite intrusive - modifies many system configs for Qubes VM use case.

One problem is HVM usage - in Qubes 3.x PV and HVM diifers much (for example you can’t switch between those modes for a VM without recreating it). It will be much better in Qubes 4.0 (HVM/PV is just a VM changeable property there), but we’re still at least few months away from having stable enough version for testing SGOS there.
Also above mentioned packages currently assume PV case. It shouldn’t be hard to get them working in HVM (maybe already does), but we haven’t checked that.

Basically I gather there is a bit of a dick-swinging contest going on in the privacy field. Otherwise they’d all come together and we could already be running layer after layer of security, which is required in today’s insane world e.g. ->

grsec kernels, piled on top of virtualization, on top of containers, on top of apparmor, on top of disposable VMs, on top of sand-boxed Tor Browsers etc etc. And that shit would “just work” TM, without an advanced degree in computer science or 1,000 steps and cryptic error messages to contend with.

From the layman’s perspective, I don’t think there is much argument that Qubes is a superior model, particularly when you look at what is on their roadmap.

Crossing your fingers and hoping that one container sandbox in Subgraph is gonna hold everything together to prevent full system infection doesn’t hold water in 2017.

PS I realized you meant add subgraph OS to that huge comparison table. I might hold off on that one for a while, since I’ve other editing priorities right now. But I’ll get there eventually, unless someone else does first.


#7

https://secure-os.org/pipermail/desktops/2016-May/thread.html


#8

I notice the developers duck and weave any follow up questions from you, Joanna, et al.

They also don’t use standard Debian packaging (and build?) procedures, thus making it hard. A year later, no progress.

Yep - it’s definitely alpha status.


#9

Well their reason for not putting a template is this https://twitter.com/bleidl/status/852136674343739392 But I agree I believe Qubes,Subgraph,Berkeley,Tor,Mozilla,eff,gresecurity,and countless others should be working together to make the internet a better place.

Btw i’m not sure if the KSPP is the way to go after reading this http://www.openwall.com/lists/kernel-hardening/2017/05/11/2


#10

Hopefully KSPP will come through (slowly). All they need is friendly x1 email from a grsec client with latest patches, and we’re all good.

grsec is now all about money, and they simply wouldn’t exist without the linux kernel, so why they continue to act like this is beyond me. Better to protect millions with upstream changes than protect a small group of clients and developers with attitude problems.


#11

Also,from my experienced with Subgraph they are quite cooperative also the day after micah contacted them about the vulnerability they got to work on it https://twitter.com/micahflee/status/851901453861965824