
Subgraph OS: Adversary resistant computing platform - mboroi
https://subgraph.com/
======
protomikron
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. My bet is that the solution is via better type systems, e.g. an
application that is a desktop game could have something like

    
    
      exec :: GameConfig -> WindowControl ()
    

where GameConfig is e.g. some CFG specific to the game and WindowControl is
similar to IO () however limited to interacting with a drawing library (e.g.
OpenGL) and input systems (keyboard and mouse local to the window).

At the moment every application just implements `main()` and is good to go and
we separate between kernel- and user-space (and a VM on top e.g. Android and
Apple), and maybe this is too coarse.

I think pledge
([http://man.openbsd.org/pledge](http://man.openbsd.org/pledge)) is also a
step in the right direction however I would prefer it to be the other way
around: an application goes through a setup process where it _gains_ the
capabilities it needs (in pledge it's the other way around, you ask to drop
them).

~~~
geofft
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 origin), and communication between
them is limited to message passing with the consent of both sites. The
language itself avoids all assumptions of direct access to system resources.

Running everything in a web app is, admittedly, a fundamental change in the
stack. But it's fortunately one where a lot of people have independently put
work into making this happen. I do my most security-sensitive work on a
Chromebook (using the SSH and mosh apps from the Chrome app store) for
precisely this reason: it's the right security model, and it's available in my
local computer store and works.

~~~
protomikron
You are right, that is the most secure platform at the moment to distribute
graphical user interface programs, but I think it should go further.

E.g. I would go so far, that it shouldn't be possible by default for the
server to send me a huge HTML/CSS/JS blob that does all kind of weird stuff
(e.g. reporting to the host, mouse movement analysis, etc.).

I am probably in a minority with the following opinion, but I think a page
shouldn't even have the ability to enforce a layout which in the end draws
pixels on your screen. The web is a step forward and HTML is a good idea, but
it is not used anymore in its intended form - it works very well for text
distribution, but richer applications have to resort to JS.

Now if you disable JS you could in theory render it as you like, but this is
far from trivial.

//edit:

Lets consider a bus company offering search to find offers that get you from A
to B (i.e. a route planner, trip finder, ...).

This app shouldn't ship you random HTML/JS, but just the information you need
to query its database, which is simply some GETing and POSTing of specified
requests. When connecting to the app (going to [https://trip-
search.example.com](https://trip-search.example.com)) the host could disclose
it self as an application having type `(From, Date, To, Date) -> Maybe
TripList` or something like that (I think one gets the idea).

The web is great, but I think security should and must go further, I do not
want run random Turing machines.

~~~
geofft
I'm not sure I get why enforcing a layout is a problem from the point of view
of application distribution - if nothing else, an app should be able to embed
a text renderer and draw onto a <canvas> itself. (It's probably a terrible
idea, but it should be _able_ to, because a text renderer is just a program
that takes in data and outputs some pixels, and that class of programs is
useful.)

I do certainly agree that we need a way of distributing hyper- _text_ content
efficiently and in a standard way. Unfortunately the web seems to be moving
away from that goal, and AMP isn't quite right and has its own problems.

I'm not sure how I feel about permissions by default. I think permission
fatigue is definitely a thing, and for most apps I don't actually care about
them exfiltrating mouse movements to the host, as long as they can only
exfiltrate it to the one host. On the other hand, I'm a little weirded out
that if I plug my piano into my Chromebook, JavaScript can receive and send
MIDI events without any permission prompt.

EDIT to your edit: I'm totally okay with running random Turing machines, if
their execution environment is constrained (which it is). The only resources
that an arbitrary Turing-complete programming language can access are any
external resources that it's specifically given an interface to, and
time/memory/power consumption. The web platform is pretty good (though, yes,
not perfect) at locking down the interfaces given to JS. So it's just a matter
resource limits, which is fairly easy; I'm not always thrilled with how much
CPU and battery life Twitter takes, for instance, but it's always killable.
(Again, in theory.)

You can construct something that's capable of using plenty of memory or power
out of any sufficiently powerful Turing-incomplete language. See, for
instance, CSS. (I bet with the mechanism you're proposing, you can end up
chaining server-side APIs in ways that let you DoS the client, because the
server is always more powerful.) And given how easy it is to achieve Turing-
completeness by mistake, it doesn't seem like a productive constraint.

~~~
protomikron
> I'm not sure I get why enforcing a layout is a problem from the point of
> view of application distribution - if nothing else, an app should be able to
> embed a text renderer and draw onto a <canvas> itself.

Yeah, but in my opinion that is already a _specific_ type of application, like
e.g. a computer game, PDF viewer, plotting application.

It is totally different from e.g. an application like Wikipedia or a news
page, that provides mostly text and images.

In the end there should just be more of the functionality on client side
(rules how to render news pages, how to render wikipedia, etc.).

------
dlevi
Does Subgraph isolate USB and network? The isolated serviceVMs for USB and
network are in my opinion a very strong value proposition of Qubes.

Furthermore, is Subgraph supposed to be an OS for everyday use, like Qubes, or
just for anonymous usage like Tails or Whonix? If its the former I don't
understand why all traffic should be routed via Tor by default - it wouldn't
make sense to route non-anonymous traffic (banking, personal mail, etc.) via
Tor. It wouldn't be anonymous anyway and also because of the unnecessary risk
of exposure to malicious exit nodes. In this sense I believe the Qubes
approach with its optional WhonixVM is superior.

If Subgraph is supposed to be for anonymous usage I'd like to read more about
what kind of threat model it is trying to address. I don't think there are any
amnesic features like in Tails nor strong isolation between gateway and
workstation to prevent IP leaks like in Whonix.

~~~
eddyl
> Does Subgraph isolate USB and network? The isolated serviceVMs for USB and
> network are in my opinion a very strong value proposition of Qubes.

According to Joanna Rutkowska, developer of Qubes: "Unlike Qubes OS, Subgraph
doesn't (cannot) isolate networking and USB stacks, or other devices and
drivers."[1]

[1] [https://secure-
os.org/pipermail/desktops/2015-October/000002...](https://secure-
os.org/pipermail/desktops/2015-October/000002.html)

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

~~~
brl
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 against other Qubes VMs to steal cryptographic keys
      - Interception and tampering with networking traffic
      - Attacks against any internal network this Qubes OS computer connects to.
    

So if you assume that remote attacks against the Linux kernel networking stack
are an important threat, the consequences of a successful attack even against
Qubes are pretty bad.

Subgraph OS hardens the Linux kernel with grsecurity, which includes many
defenses against exploitation which have historically prevented local
exploitation of most security vulnerabilities against the kernel. Exploiting
kernel vulnerabilities locally is so much easier, probably never less than an
order of magnitude easier. It's so rare to reliably exploit kernel
vulnerabilities remotely even against an unhardened kernel that teams present
papers at top security conferences about a single exploit:

[https://www.blackhat.com/presentations/bh-
usa-07/Ortega/Whit...](https://www.blackhat.com/presentations/bh-
usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf)

I know it's contentious to say so, but I don't believe that anybody will ever
remotely exploit a kernel vulnerability against a grsecurity hardened Linux
kernel, especially since RAP was introduced:

[https://grsecurity.net/rap_announce.php](https://grsecurity.net/rap_announce.php)

The threat of remotely attacking the Linux kernel through the networking or
USB stack was always low in my opinion, but as the threat approaches zero it
raises some questions about how justifiable the system VMs are in Qubes OS
considering the system complexity and usability impairment they introduce.

~~~
hrehhf
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 be very difficult to attack the
NetVM. It is only the AppVMs or any others which run applications that are
vulnerable, and if these are attacked, Qubes's design will likely prevent a
permanent backdoor from being installed in that VM and make it difficult for
the attacker to gain access to any of the other AppVMs.

I still think Subgraph looks promising and I look forward to your future work.

~~~
brl
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.

------
Animats
They try to avoid saying it, but it's mostly a patched Linux.

~~~
xdma
Hi, I'm an SGOS dev. I don't know what you mean by "mostly a patched Linux",
but here's what Subgraph OS is so far -- and it's a young project: we have a
kernel patched with grsec/PaX/RAP, but we have also developed our own
application sandbox framework (namespaces + limited fs + seccomp bpf
whitelisting), app firewall, event monitoring subsystem, usb disable on
desktop lock (based on grsec), etc. Here's a walkthrough of our sandbox
framework:

[https://github.com/subgraph/oz/wiki/Oz-Technical-
Details](https://github.com/subgraph/oz/wiki/Oz-Technical-Details)

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

~~~
mtgx
You may find this talk between the Qubes, Subgraph and TAILS representatives
helpful:

[https://www.youtube.com/watch?v=Nol8kKoB-
co](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/](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...](https://secure-
os.org/pipermail/desktops/2015-October/000002.html)

I believe initially there were some discussions to integrate Subgraph into
Qubes as a TemplateVM (just like the Debian VM, Ubuntu VM, etc), but the
Subgrapth guys thought Grsecurity wouldn't work well with Qubes OS. I think
that situation has improved, and there is some progress in making Grsecurity
work with TemplateVMs and AppVMs.

[https://twitter.com/Phoul/status/801114260881424384](https://twitter.com/Phoul/status/801114260881424384)

However, even if it does work, I'm not sure how excited the Subgraph guys are
about making their OS "just" a Qubes OS TemplateVM. They may think that's the
wrong business strategy for them as a company. I'm just saying this as someone
watching from the outside. They may actually not believe that at all.

However, I did also notice the relationship between the two projects got a
little colder, at least for a while, and in public, after Edward Snowden
called Qubes his preferred secure OS.

~~~
xdma
It was me, at Subgraph, that setup the Secure Desktops mailing list and
website. We hope to collaborate more with other projects in the future. There
is already interest from other projects in things we've built for Subgraph.

As for Subgraph in Qubes, being a template OS, etc, maybe later? We haven't
even had a real release yet and are still building. I wouldn't recommend it
anyways unless all of the Qubes VMs have hardened kernels by default.

------
stcredzero
I rather like the graphic with this post. Is that based on pixel art,
programmatically combined to resemble orthographic projection, or is it
generated by WebGL? (Using one of the available blocks libraries in
Javascript.)

~~~
xdma
It was drawn by hand using a vector illustrations tool, based on a sketch that
I had made. We think it is very cool and will produce more conceptual
illustration in this style.

The artist goes by Sephy Ka: [http://www.sephyka.com/box-
stories/](http://www.sephyka.com/box-stories/)

------
formula1
Ill give it a shot. Ive been feeling quite vulnerable on 16.04 due to the
absurd amount of unfixed bugs. I have a couple of questions

\- its mentioned that it __does not __have access to documents and downloads
within the user folder. When it wants /needs read access, how am I told?

\- if it doesnt have access to these folders, does it only write to its own
subset?

\- is it possible to make my home downloads folder an aggregate of the
application downloads?

\- when uninstalling/purging, since its sandboxed it deletes all of the
content or keeps it? Can I force removal as well?

\- how does subgraph deal with shared services/folders/info? Can I share a
service with another user? Can I share the network setting modifications with
other users?

\- how can I prevent an application from using the network without my
knowledge?

\- are the tools like nethogs/top for subgraph that can take advantage of the
compartments to show a more realistic view of whats going on?

I think this has a lot of potential!

~~~
xdma
These are great questions. We have a Gnome shell plug-in to move files into
sandboxes while an application is running. Certain applications also have
shared directories (e.g. "Downloads/TorBrowser", "Documents/LibreOffice").
This is a UX work in progress though, neither of these are adequate, though
together they're workable.

re: Applications and network access: we have an application firewall, unique
to Linux-based OSs. It's basically Little Snitch for Linux. There is a
screenshot here:

Keep in mind that the project is very young. We are just getting started, tbh.
With questions like these you should idle in our IRC channel where we talk
about all of this stuff: OFTC/#subgraph.

~~~
formula1
Will do! Im very excited for this. Containerization and safety is a very
important problem to me. Im not particularly interested in running a docker
instance or a vm just to use an application. And if I do, id prefer it being
automated.

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

------
runeks
Looks interesting. I'm looking for a more secure minimal OS, for use with
backend services. Would it make sense to use it as a server OS, or is it
primarily for desktop use?

Also, is there a docker image that is ready to go? That would be immensely
useful.

~~~
xdma
It's a desktop OS, and the hardened kernel is an important part of the project
(i.e. no docker image).

------
verandaguy
"Adversary-resistant" is an extremely bold claim. While the architecture does
look promising, and (at least intuitively) reasonably-designed, I think it's a
bit too soon to make a call about adversary resistance.

~~~
jcoffland
The word "resistant" is qualitative so they are not really making a bold
claim.

~~~
mtgx
Yes, just like water-resistant vs water-proof. Subgraph OS is like hacking-
resistant, not hacking-proof.

------
rrggrr
I need to know who/how they made the graphic image. I love it.

~~~
akerro
[https://news.ycombinator.com/item?id=13026642](https://news.ycombinator.com/item?id=13026642)

------
tscs37
For a second I thought this was about a new linux-distro for servers that
featured outage resilient services and such.

Oh well, this is good enough I 'spose.

------
tonyplee
Care to put out a vm image, invite folks to hack it?

That is a lot more interesting.

~~~
xdma
You can install/run the downloadable image in a VM. Lots of people do. We test
with VMWare Fusion/kvm/Virtual Box.

