Live data from Hacker News

Subgraph OS: Adversary resistant computing platform

subgraph.com

71–80 of 88 posts

Re: Subgraph OS: Adversary resistant computing platform

#71
post #70
post #64

Earlier quoted context omitted.

I'm from Subgraph and I disagree. On Qubes OS the networking VM runs a standard Linux kernel with no special security hardening at all apart from the simple fact that it runs in a separate Xen VM. If an attacker is able to compromise NetVM, they may not have direct access to user data, but they have dangerous access to perform further attacks: - Attacks against hypervisor to break isolation - Side channel attacks aga…

I agree with your comments about grsecurity making the kernel much more secure. However your comments about remote exploits and Qubes are somewhat contradictory. You claim that a remote kernel exploit is very rare/difficult, therefore the Qubes NetVM must be very difficult to attack because it runs no applications or services. It functions as a router and does essentially nothing else. By your own argument it would b…

I'm answering a comment chain about how Subgraph OS does not 'isolate' the network or USB stacks which is frequently brought up as an important deficiency in comparison to Qubes OS. My point is that this isn't a significant advantage of Qubes because such attacks are rare and difficult, and because they're even harder to perform against Subgraph OS.

I wasn't talking about AppVMs at all, but you can of course persistently backdoor Qubes AppVMs in numerous ways by writing to the user home directory. In Subgraph OS we design our application sandboxes to prevent exactly this.

Re: Subgraph OS: Adversary resistant computing platform

#72
post #32

This is a step in the right direction (in the sense that we should sandbox applications harder), but in my opinion we have to change fundamental aspects of our stack (e.g. Proprietary Firmware Linux GNU-System-Libs X GTK Evince), to gain more security. In particular I think it is harmful that all applications share the same view on the FS and have in principal the possibility to use e.g. full unixoish capabilities. M…

The well-developed, well-security-researched, well-deployed application platform you're looking for is the web. You get exactly this sort of setup if you use WebGL: you interact with an API that expects to be called by unprivileged hostile applications, instead of with a library that helps your direct access to the graphics card driver. Every individual application lives in a separate protection domain (an HTTP origi…

Serious question - what's the difference between that, and running all apps in their own chroot jails?

It seems like the goal of this app is to isolate things from the network, and from each other. A web app or chromebook method isolates from other apps, ok, fine, but not from the web. Seems more like jail in that sense.

Maybe I'm just misunderstanding.

Re: Subgraph OS: Adversary resistant computing platform

#73
post #61

Earlier quoted context omitted.

Sorry for being OT but do you mind explaining a bit what exactly does Genode do/is? I read about it in their web page but I'm not sure I understand the difference between "an OS" and "an OS framework". It seems that they are trying to create an architecture with all components compartmentalized, but it says it can run Linux and Windows so I'm guessing it's virtualizing something at some point. Also, they say they hav…

There's a lot of conceptual similarity to Nizza architecture that's explained thoroughly in this paper: https://os.inf.tu-dresden.de/papers_ps/nizza.pdf From there, Genode is a different take on the same concept even using some of the same components (eg Nitpicker GUI). In both, there are various components integrated that might be used in other projects. A specific set of components together makes up a desktop. A di…

Awesome! thanks a mil.

I'll read up the linked resources.

Re: Subgraph OS: Adversary resistant computing platform

#74
post #64
post #57

Earlier quoted context omitted.

Thanks for that - it pretty much answers my question. In this case it seems that Qubes exposes less attack surface.

I'm from Subgraph and I disagree. On Qubes OS the networking VM runs a standard Linux kernel with no special security hardening at all apart from the simple fact that it runs in a separate Xen VM. If an attacker is able to compromise NetVM, they may not have direct access to user data, but they have dangerous access to perform further attacks: - Attacks against hypervisor to break isolation - Side channel attacks aga…

Thank you for your answer, I'll definitely look further into SubgraphOS and grsecurity. I nevertheless believe that the kind of attacks you describe, specially the one against hypervisor in NetVM to break isolation, are quite unlikely in Qubes.

Could you also answer my question about SubgraphOS main use case and threat model?

Is it mainly for anonymous and pseudonymous usage?

If it is designed mainly for everyday use (including non-anonymous use cases like banking, social media, personal/work email, etc.) as it seems to me I don't quite understand the design choice to enforce all traffic via Tor by default. That seems unnecessary as anonymity is not needed and even dangerous.

Re: Subgraph OS: Adversary resistant computing platform

#75
I come late to the party but I installed the ISO on virtualbox. It seems after boot, I can't apt update or anything network related.

I tried disabling the firewall too, to no avail.

I see that /etc/resolv.conf is only having nameserver 127.0.0.1 I guess that's ok (resolv made through Tor maybe ?) but I wonder how to activate the network :/

Is there a way to discuss things related to Subgraph ?

thanks

Re: Subgraph OS: Adversary resistant computing platform

#77
post #16

Earlier quoted context omitted.

Yup. Subgraph is a nearly 7 year old open source software company. We wrote a web scanner (Vega) that's sadly neglected, though still used regularly by thousands of users. We also do consulting, like pentesting, etc. The name was inspired by work I was following at the time (10 years ago?) by Halvar Flake etc, on applying graph theory methods to reverse engineering / runtime analysis.

It's catchy, sounds technical, and non-technical people can still spell it. Great name. :)

It is a precise technical term, and using it for a company name is unsettling to a graph theorist. But, it's probably cool for almost everyone else.

Re: Subgraph OS: Adversary resistant computing platform

#78
post #40

Earlier quoted context omitted.

Hey, cool project! Any chance you could give a quick rundown of how this compares to Qubes? Like, the tradeoffs, etc.

You may find this talk between the Qubes, Subgraph and TAILS representatives helpful: https://www.youtube.com/watch?v=Nol8kKoB-co I believe Joanna from Qubes also set-up this forum for discussions on secure operating systems: https://secure-os.org/ Joanna also talked a bit about the trade-offs between the two here: https://secure-os.org/pipermail/desktops/2015-October/000002... I believe initially there were some dis…

Thanks for the interesting stuff.

Even if Snowden called out Qubes, you have to decide on your own security level which system is best for your needs.

Re: Subgraph OS: Adversary resistant computing platform

#79
post #40

Earlier quoted context omitted.

Hey, cool project! Any chance you could give a quick rundown of how this compares to Qubes? Like, the tradeoffs, etc.

You may find this talk between the Qubes, Subgraph and TAILS representatives helpful: https://www.youtube.com/watch?v=Nol8kKoB-co I believe Joanna from Qubes also set-up this forum for discussions on secure operating systems: https://secure-os.org/ Joanna also talked a bit about the trade-offs between the two here: https://secure-os.org/pipermail/desktops/2015-October/000002... I believe initially there were some dis…

Having a subgraph TemplateVM will get easier with Qubes 4.0, as Qubes switches over to HVM (I think just HVM with PV drivers, PVH in Xen is not ready yet). grsecurity and PaX do not work with paravirtualization, which is pretty limiting in terms of memory management and such (It also opens up some vulnerabilities, which is why Qubes is switching).

Re: Subgraph OS: Adversary resistant computing platform

#80

This is a step in the right direction (in the sense that we should sandbox applications harder), but in my opinion we have to change fundamental aspects of our stack (e.g. Proprietary Firmware Linux GNU-System-Libs X GTK Evince), to gain more security. In particular I think it is harmful that all applications share the same view on the FS and have in principal the possibility to use e.g. full unixoish capabilities. M…

Any solution which requires rewriting existing software is impractical. There's nothing wrong with an application having the illusion of full control of the system that sandboxing provides. I'd like to see an OS where all applications are run in a sandbox (e.g. LXC containers). Each application should have metadata which describes what special access it needs (e.g. Android's permissions) but the user is free to enable or disable these permissions at will. Applications can work as they were originally written because any access they expect to have that was denied by the user can be faked. For example, say an application requires access to a database containing your personal contacts. Instead of blocking the application's access completely and requiring the application to correctly handle the case when accesses was denied, the OS can provide a dummy contacts DB instead. The application then proceeds as normal without knowing access was denied. Firewalling in both directions like SubgraphOS is doing is also essential.
Post reply on HN