QubesOS Template

[ghost]

I'd like to open up an issue where we can discuss what needs to be done in order to get a SGOS template for QubesOS. Is there anything keeping us from using SGOS in QubesOS at the moment?

[ghost]

CC @rootkovska @marmarek

[marmarek]

Thanks for creating this issue!

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.

Most likely I've forgotten about something here, will post an update in such a case.

[paymonyaminisharif]

random important thoughts on the subject:

note: ive been running qubes as my primary machine since the original alpha. someone asked me why i never filed a bug report and i figured its probably because i am annoyed that the qubes people dont use qubes as their primary computing platform and they are very slow to fix bugs and sensitive to criticism. that said, qubes-os is one of the most important projects in human history. it is the first operating system manifestation of attack surface mitigation through isolation and separation moving up and down through all the modern layers of virtual abstraction - in the computational sense - to create an ecosystem/interface that both promotes and enforces secure human operating procedures or workflows... and the architecture is truly elegant. the developers are in a world of their own. i dare say that projects such as subgraph and qubes belong somewhere in the same chapter as openbsd (its a bit early to say they are on the same page... i'll save that compliment for the next decade if everyone keeps their shit together).

the devs have a theory that either redhat or oracle is going to buy them (dafuq?) and the obsession with pv is unnecessary (fast sec is best sec lel?!). i believe that this implementation should lean towards HVM first and have a sane upstream technology supplychain. qubes is a wonderful security technology in the form of a framework, but the qubes-os distribution is an ugly and ill-organized mess. the choices they made like kde, fedora, obsession with pv, no domu security whatsoever, etc etc are testament to both how successful attack surface mitigation through isolation can be and how understaffed and underfunded qubes is (not to mention unappreciated and maybe even a little unimaginative).

i think we shouldnt start with debian template and make subgraph. we should start with whonix-ws template. if we can produce a disposable whonix-gw based subgraph implementation we will have solved all possible problems above the hypervisor on qubes (with respect to the problem in question). the next step is to get a subgraph based dom0 (obviously most of subgraph will not be necessary in dom0 for qubes but that doesnt mean we should have something retarded there like fedora+kde. orthogonality is one of the pillars of computer science and qubes fails here miserably). if they put their egos aide and apply the same standard of excellence to the distribution that they have applied to the framework they will adopt all of this upstream... if not we'll have "whosubqubesnixgraph-os" and more users will be running qubes on subgraph than qubes on qubes-os (because it will be obviously better). that should teach them to defy the majesty of my most excellent demands (ok just trying to be funny here for all you autistic geniuses out there)... im sure the whonix people will adopt it immediately so maybe the qubes people will take a hint early. if not i will just laugh for a longer period of time.

one thing that has not yet been mentioned anywhere is having metaproxy with whonix-gw and various challenges providing a consistent and sustainable secure-workflow experience. eventually subgraph needs to have tight integration with whonix-gw. this is a discussion for after many milestones though.

relevant: https://secure-os.org/pipermail/desktops/2016-March/000107.html

[adrelanos]

@ghost

Is there anything keeping us from using SGOS in QubesOS at the moment?

Subgraph OS is not Open Source yet. Reference:

Where to find subgraph os Debian package source code?
https://secure-os.org/pipermail/desktops/2016-May/000118.html

Do you have a ticket for that yet?

Is subgraph os more than its Debian packages?
https://secure-os.org/pipermail/desktops/2016-May/000119.html

@marmarek

Is it possible to (easily) convert standard Debian testing installation into SGOS?

Unfortunately, it has not been answered yet if Subgraph OS is more than its Debian packages. And the source code for the packaging has not been published. If there was a list of packages (or ideally a meta package) that defines the diff between Debian testing and SGOS, then that might be doable.

[whatisgravity]

This needs to be open sourced.

[matthaab]

It is open sourced now, right?
https://github.com/subgraph

[xSmurf]

@matthaab yes it is, all of the relevant code is up on github (and already was there). Some patches to live-build are not, but they are not particularly relevant either (ie they don't affect the outcome, just working around some bugs from upstream). If you see something specific we may have missed let us know.

[adrelanos]

It is open sourced now, right?

Has some non-subgraph os developer managed to build a subgraph os ISO from source code yet?

[EmailTaken]

@adrelanos

I'm nowhere near a Dev and I've got it running as my main and only operating system. It's great!

[brl]

This ticket is becoming a source of and a reference to too much misinformation about our project.

Subgraph OS has always been Open Source. All source code for all custom components are on Github and have always been there. It took us some time to develop correct Debian packaging due to the our initial inexperience with Debian and the special complexity of packaging Go language applications. We have mentioned this before and nobody offered to help.

Nobody has ever tried to build an ISO that we're aware of or asked us for help to do so. It's always been technically possible to build your own ISO, but until recently the process wasn't very well documented and at times the build required some manual intervention for reasons beyond our control.

It was rather inconvenient for us when the only Debian live-builder maintainer quit suddenly over internal Debian politics:

https://lists.debian.org/debian-live/2015/11/msg00024.html

I'm going to close this ticket and I invite anybody working on creating a template for Qubes to open new tickets for any specific obstacles that we can address.

[adrelanos]

@brl:

Nobody has ever tried to build an ISO that we're aware of or asked us for help to do so.

I asked How to build subgraph from source code?

However, I failed to build Subgraph OS since it is too difficult. David McKinney had agreed about a missing snapshot apt repository.

Quote David McKinney

We're setting up our own repos that will allow us to stage stuff from testing and provide snapsnots. It will also make it easier to live-build Subgraph OS as the patched version can be obtained from our repository.

Created use snapshot.debian.org and/or provide snapshot repository to allow anyone building Subgraph OS (#240) for it.

---

My other questions Is subgraph os more than its Debian packages? and What is the status of the subgraph deb apt repo? / What is the status of debootstrapping subgraph? were also supposed to deepen my understanding of Subgraph OS internals. Because if the answer would be "yes", then it may be not too difficult to create a Qubes template with Subgraph OS.

---

@brl:

I invite anybody working on creating a template for Qubes to open new tickets for any specific obstacles that we can address.

Sure.

• fix devrepo.subgraph.com to aid Subgraph OS build process understanding (fix devrepo.subgraph.com to aid Subgraph OS build process understanding #238) would help.
• sudo apt-get install subgraph-os / debootstrap Subgraph OS (sudo apt-get install subgraph-os / debootstrap Subgraph OS #239)
• use snapshot.debian.org and/or provide snapshot repository to allow anyone building Subgraph OS (use snapshot.debian.org and/or provide snapshot repository to allow anyone building Subgraph OS #240)

[tildelowengrimm]

I have opened #250 to stand in for the specific things I wanted out of this issue.