Qubes-Air? Qubes in the cloud?

General Discussion
60

This is not what “control” means. Dom0 runs on your own computer and you still have full control over it, even though it’s not pure Linux. It’s just different software. It’s like saying that after installing Linux you do not have any control over your PC, because your are used to run Windows – totally missing the point.

Same about Qubes Air. You choose where dom0 (or whatever will replace it) runs and you have full control over its source code and running options, even if it runs something minimal, even if it runs in (your) cloud. It’s just a choice of the operating system. If Qubes OS 5.x becomes an OS that you don’t like, you are free to continue using 4.x, but it wouldn’t mean that you lost contol of it.

It is still a goal and I think discussing it is a good thing.

2 Likes
67

… since there are other ways than IP to communicate over TCP/IP… Of course, I wansn’t ask to elaborate this earlier…

68

I don’t think it’s even possible to run dom0 remotely and not on your hardware.

Dom0 is the initial domain started by the Xen hypervisor on boot. Dom0 is an abbrevation of “Domain 0” (sometimes written as “domain zero” or the “host domain”). Dom0 is a privileged domain that starts first and manages the DomU unprivileged domains.

The Xen hypervisor is not usable without Dom0. This is essentially the “host” operating system (or a “service console”, if you prefer). As a result, Dom0 runs the Xen management toolstack, and has special privileges, like being able to access the hardware directly.

https://wiki.xenproject.org/wiki/Dom0
Sure your AdminVM can be run on some remote host (don’t know for what purpose though) but not dom0 so let 's clarify whatever you’re talking about dom0 or AdminVM.

70

There’s so much to read.

71

This just occured to me, but should have been obvious at the start:

If Qubes Air doesn’t use quantum-resistant (or better yet, quantum-proof) cryptography, the whole system is asking for those who want to snoop on you (or Qubes users in general) to copy and store your encrypted data and wait for quantum decryption to be cheap enough.

Quantum-assisted decryption isn’t that far off, if it isn’t here in some form already (the element of surprise it gives is really valuable). It might not even take long enough for statues of limitations to be passed in some places, if legal action is a concern.

In other words, Qubes Air without quantum-resistant (or better) cryptography is very risky.

This also applies to online traffic in general (instant messaging, cloud storage, etc.).

72

I split the topic to clear it from offtopic posts. But this should probably be quoted here:

73

Sorry I wasn’t more specific at the moment.

This is just one of spots as far as I can recall. I was speaking about future plans, not about current dom0 configuration.

Again, and again. I didn’t claim anything like that. If so, please point it again. What I was saying is that it’s obvious that if TCP/IP communication is considered to be the protocol (beside qrexec), and we can see that in the diagrams, then what other way than via IP is possible? For me, that is what was obvious.
The question is simple: do we see TCP/IP in diagrams? According to this, how the communication will be held?
And, if it’s only an article, why it is said it is actively developed?
I just don’t understand these contradictions.

74

I don’t see how it’s obvious that dom0 can become something like Intel ME. Well, if you are using someone else’s Qubes OS and you don’t have a root (or dom0, or whatever admin) access, then it could be similar in some sense. However, it has nothing to do with Qubes development plans, or intentions of the developers, does it?

Indeed, you need some communication protocol in order to have communication between different parts of Qubes Air. It could be TCP/IP, but it could also be done via I2P to obfuscate and mitigate many attacks.

The third diagram explicitly says “Qubes GUI over TCP/IP” and “Qubes qrexec over TCP/IP”. Does it answer your question?

It depends on what you mean by “actively developed”. Developing sys-gui and sys-audio is AFAIK a milestone towards Qubes Air, even though it’s not Qubes Air development per se. You can’t develop Qubes 5.x before you are finished developing Qubes 4.x.

75

qubes-remote-support looks quite good thing for me. I see it’s main use for me in having secure access to your server with QubesOS installed over the network.
@marmarek said that it won’t be preinstalled in Qubes and you’ll need to install it manually if you need this function:

You can read the links in the issue to get more info on this package.

76

This is mentioned in the 4.1 Release Notes:

Optional qubes-remote-support package now available from repositories (strictly opt-in, no package installed by default; no new ports or network connections open by default; requires explicit connection initiation by the user, then requires sharing a code word with the remote party before a connection can be established; see #6364 for more information)

77

Wait, sorry I won’t answer your comments at the moment (avoiding digressions, spinoffs, etc):

  1. You are commenting actual state (even that wrongly - first you say I don’t think it’s even possible to run dom0 remotely and not on your hardware. than - ohm, there it is, I like it. Well I don’t.). And without asking yourself where this can, will lead to? I was very clear that it is stated there in the docs - without direct access to dom0. If this is not true anymore, than maybe you might consider to change the statement?
  2. But if it is, I assume this statement will lead us not to access dom0 at least directly. Does this mean instead of today’s remote, tomorrow’s direct access to dom0 will be strictly optional with

no new ports or network connections open by default; requires explicit connection initiation by the user, then requires sharing a code word with the remote party before a connection can be established (TCP/IP I emphesized from the diagrams)?

Is this simple, legit question asking for simple yes/no answer backed up with some official link? Mentioning remote access to dom0 several years ago was/would be considered as heretic, yet today we have it, as an option for now. So, tomorrow will be…?
3. Where is the dom0 actually in this concept? If no one knows, that isn’t good (“let’s go and we will see where we will end up”?). But I’m sure this isn’t the case, you people are taking this project more serious and meticulous than anyone else their.

I was heavily taken for the words and contexts I never wrote or meant about, while at the same time I’m quoting official docs and team members (deeplow mentioned somewhere it is actively developed, I had all the links and docs needed for this discussion opened, then “cut the FUD” actually cut my disp TorB and now I have to collect them all again), and I have a feeling I’ve been told that it is not written what we all can read.

And I’ll repeat for the last time: I’m not accusing/putting the blame on anyone for anything: this is your private project and you can do with it whatever you think is good (and as of May '22 it’s perfect to me), I’m just trying to comprehend where it is heading to.

1 Like
78

I did ask this myself and my answer to myself was “it will be amazing”. Not sure what else one could foresee and why.

From your wording, it’s quite unclear which my statement you mean here. Could please be more specific, with quotations?

Not yet. Also, it will not be called dom0 but Admin qube:

A “local copy” of an Admin qube (previously referred to as the “AdminVM”), used mainly to orchestrate VMs and make policing decisions for all the qubes within the Zone. This Admin qube can be in either “Master” or “Slave” mode, and there can only be one Admin qube running as Master across all the Zones in one Qubes system .

Perhaps I see where you are heading here. No, your conclusion is not logical. You can’t simply have “optional” access to the Admin qube by default. In this way, there is just no way to manage your operating system. If you install it, then there must be a way for you to manage it and there must be non-optional access of the Admin qube. Otherwise, Qubes would be not usable by anyone.

I expect that by default Qubes installation will be configured in the same way as currently: for the local usage.
If you want a cloud-related configuration, you would have to install Qubes on several devices and then configure which one(s) will be Admin qubes and which ones will follow the orders. In any case, you have the non-optional access to the Admin qube.

Here is the quote from the original link:

Rest assured that we will also discuss other solutions not involving the cloud. The beauty of Qubes Air, we believe, lies in the fact that all these solutions are largely isomorphic, from both an architecture and code point of view.

It strongly depends in which context you are mentioning the remote access to dom0. Default remote access was a disaster and is still a disaster. This would be against the whole Qubes approach to security, making all many-year work useless. From this point of view, nothing has changed: dom0 is still offline, unless you really want otherwise. If a hacker can install the remote access tool in your dom0, then you already lost the battle before it’s done and whether such package exists or not.

I see where you’re coming from. Indeed, many proprietary projects start as extremely useful, then extend their functionality to the cloud and then cut the offline option forcing the user into the cloud. One recent example coming to my mind is ReMarkable tablet. However, I do not know of any free-software-based projects going this way. Can you give an example? This is the whole point of the 4 freedoms of free software: you can’t just do this without loosing your users, because there is no walled garden keeping them in.

As I mentioned above, dom0 turns into Admin qube, which can physically reside on a different hardware. I think it’s explained in the Qubes Air article quite well.

1 Like
79

I’ll be away for sometime and will not reply soon. But I thank you for your clarifications. They’re not of the value to me only, and you probably knew this even before you started to type.
Great example!

1 Like
80

There is no mention anywhere (at least I didn’t see it) that the remote-controlled system will be default QubesOS installation with packages like qubes-remote-support preinstalled.

There is a difference between running dom0 remotely and controlling dom0 remotely.
When I said that it’s not possible to run dom0 remotely I was talking about network boot of dom0 by Xen with PXE or something. I don’t think it’s possible.
But remote control of dom0 - sure you can do this even without installing some package like qubes-remote-support:

From my point of view without direct access to dom0 mentioned in the docs meant the same thing as with Xen. You can’t access Xen directly and can only control it using interfaces that Xen gives to dom0. The same thing seems to be the goal for Qubes - you won’t be able to have direct access to dom0 and you’ll be able to control dom0 only from some AdminVM using interfaces that Qubes will give you.
I have some concern over this as well if you won’t have access from AdminVM to some of dom0 functions that won’t have implemented interfaces in AdminVM for some reason (not yet implemented because of low priority feature / disabled for security reasons). But there should be some hack to configure what you want in dom0 even if it’ll be a pain.

I don’t think the restricted access to dom0 in this case is about running dom0 remotely but by restricting it like Xen as I stated above.

It should still run on your hardware as Xen privileged guest:
https://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide

81

A “local copy” of an Admin qube (previously referred to as the “AdminVM”),

And AdminVM was never dom0, unlike vice versa. This is crucial thing that confuses me, and I’m referring to it again since you mentioned it

If you were right, wouldn’t Joanna wrote:

A “local copy” of an Admin qube (previously referred to as the "dom0”),

I don’t get you here. It is clearly stated in the docs

without direct access to dom0

These are not my words or assumption.

Based on what writing? Any qoute?
On the either hand the whole Joanna’s article you quoted too, is about "cloudification’ of Qubes.

And off the topic a bit, the main reason for Qubes Air is hardware compatibility, so the answer to this is:

Above, we discussed how it’s possible to move Qubes VMs from the user’s local machine to the cloud (or to physically separate computers) without the user having to notice. I think it will be a great milestone when we finally get there, as it will open up many new applications, as well as remove many obstacles that today prevent the easy deployment of Qubes OS (such as the need to find and maintain dedicated hardware).

OK, so who has the proper hardware to host Qubes on cloud?

The more I think, the more dilemmas. OK, I don’t have proper hardware. You have it and you host the Qubes on your hardware in the cloud. So, I have to rely on you that you have proper hardware, and that your Qubes won’t be compromised and then my VM too?
Or, next scenario, VM is considered to be compromised by default. This applies to wherever VM is. So, although you have a proper hardware, the VM you host for me is compromised anyway, and since I don’t have proper hardware, and I access compromised VM, I am again under the possible at least side channel attack. So, where is exactly the benefit for me you to host my VM?

Jesus Christ, I must be torn down by my age…

As @Sven would say - Cloud down, I’m down…

Discuss, unlike the statement from the above again:

Above, we discussed how it’s possible to move Qubes VMs from the user’s local machine to the cloud (or to physically separate computers) without the user having to notice. I think it will be a great milestone when we finally get there, …

So, no discussion about cloudification, but no-cloud - maybe, right? Or, it’s a language barrier?

Exactly. Am I finally comprehended. And to backup my fears, read my previous paragraph. With the slight correction - not cut off but to make local option so inferior to cloud, that it just would be pointless to use it. And for such scenarios, you probably heard about much more then for a total cut off.

Whole Joanna’s article is wrapped in a “convenience wafer”. So, let’s see if we’ll get increased security and/or privacy from clouded Qubes:

This approach may trade security for convenience (if the endpoint device used to access Qubes-as-a-Service is insufficiently protected) or privacy for convenience (if the cloud operator is not trusted). For many use cases, however, the ability to access Qubes from any device and any location makes the trade-off well worth it.

Wow!

I’m not naive. So much went to the cloud, and finally, everything will. It’ll happen maybe after Qubes 6, or later most probably, just as GUI domain was first mentioned ten years ago and it happened. Nothing is mentioned by accident, and this doesn’t implies evil plans and evil devs. It implies legit roadmap I can like it or not. Why it looks to me that this is obvious yet denied (only by you and @adw)?
By the devs, it isn’t, I just find it offendable that explanation for the roadmap is - “it’s better for me”, or “no, it won’t happen”.

82

And I am very well aware that I’m acting as I found a giant jewel, and now afraid it’ll be cut into pieces and hosted in other’s vaults because it’s better for me…

83

I’ve been an advanced Qubes OS user for about 10 years since R1 days and have followed Joanna’s & Marek’s posts regularly and community discussions semi-regularly.

I absolutely hate The Cloud. I’m the type of user who customizes my Qubes for greater security and privacy, writing my own utilities and scripts to go well beyond what the already great Qubes OS provides by default. If the Qubes OS project ever made third-party cloud hosting of my Qubes mandatory, then I would barf inside of a cube and mail it to the devs, anonymously of course. Seriously, Fsk The Cloud (other people’s computers).

That said, I was pleasantly thrilled to read Joanna’s vision/plans for Qubes Air, and can’t wait for Qubes Air to come to fruition.

While these hybrid computing concepts can be confusing to the average-skilled user, it was quite clear by the original postings that there was no vision/plan for any mandatory third-party cloud requirements or limitations. It was also clear that locally-running Qubes OS (as it is today) shall always be possible.

However, even though I hate The Cloud with a passion, I am very eager to consistently use the cloud features of Qubes Air.

While I truly hate The Public Cloud, I do very much love My Private Cloud (secure local network of devices).

With Qubes Air, I can’t wait to have my local desktop machine act as a Qube Server, and my other mobile devices act as Qube Clients, such as my laptops, tablets, maybe phones one day, etc, running/integrating Qubes all within my own tightly controlled private cloud (local network of computing devices exclusively within my home).

This Qubes Air implementation would securely and privately alleviate numerous pain points with running several local Qubes OS devices together. By reading the original posts, this clearly was part of the original envisioned plans for Qubes Air, and as a hater of The Public Cloud, I can’t wait to run Qubes Air on My Private Cloud of local, networked, trustworthy devices.

From consistent behavior over 10+ years, it is clear that the Qubes OS devs and team also have a healthy respect, culture, and userbase that supports owner controlled computing principles. While it is totally fine that Qubes can be seamlessly networked together, whether across a LAN, WAN, or the internet, and whether across first-party or third-party infrastructure/computers, it is vital that no third-party internet requirements be mandatory. And it was very clear to me, from the original postings, that no such bad requirements would be mandatory, and that local Qubes OS computing would always be available as it is today.

Could there be some conspiracy to make Qubes OS into a third-party internet-cloud ONLY hosted system over time? That’s just an farfetched possibility that has no basis in the demonstrated reality of what the Qubes OS project and people are about. And the Qubes project is easily forked and re-released by us cloud-contageous local-loving community developers if the Qubes team were to ever sell out and stop supporting local-running Qubes. Build and sell Qubes as a Service all you want, but always allow Qubes OS to run offline, locally on one PC or optionally locally on multiple PCs/devices. After being with Qubes OS from since the early days, and reading the Qubes Air postings multiple times, I see no reasonable indication that the Qubes team is planning anything bad here, which I and others like me would dislike on our machines. Easy to fork and re-release, if some great conspiracy makes me wrong though.

Fear not, fellow community members, Qubes Air should be a great enhancement (and entirely optional), which can actually help us users who love our locally-running security and privacy systems, and who hate The Cloud with a passion.

Think of the very neat possibilities of running a Qubes Desktop Server and then branching (locally networking) off of that server with your mobile devices, such your laptops, tablets, and maybe phones one day, in order to have an integrated cross-device Qubes environment working seamlessly together, which is all locally networked and kept far away from The Public Cloud if you choose (or even totally air-gaped offline).

If you hate The Cloud like me, then you should still want Qubes Air, as it is optional and also very useful within Your Own Cloud (your own private/secure local network of devices).

4 Likes
84

I couldn’t agree more, I don’t see how anyone loses anything from the proposed design concepts.

If you don’t want or don’t need the cloud feature, I don’t see anything that would stop you from running the service locally without connecting it to any other systems. I don’t see how that would be a major change from what we have today.

I really can’t see how the option to use public or private cloud is going to hurt anyone.

The idea of having a powerful PC/Server at home which you can use from a secure laptop when away makes a lot of sense to me.

1 Like
85

To this - amen from me. Until all the hardware is mine, dom0 is with me, and nothing is other’s.

Again, where exactly it says so? @fsflover tried to find it, but dom0 is never to be found in the article, only Admin qube was mentioned by Joanna and she referred to it as an “AdminVM”, and what “AdminVM” is you can read here:

and here:

for example

86

This is correct.

This is not yet the case, so saying “previously referred to” would be wrong here.

OK, this is a misunderstanding caused by a large number of the underlying context here.

  1. Someone must have a full access to dom0/admin part of Qubes OS in order to manage the Qubes OS installation. Otherwise the OS would be useless for everyone, including any “evil corporation”, if it ever might seize the control. Conclusion: the controlling part (however it’s called) will always be a part of the OS.

  2. If you have the full source code, including the “dom0/admin tools”, you can always install it such that you have the full control, cloud or not. Qubes OS license is GPLv2. Conclusion: You will always have the access to the source code and full control over the OS.

Rest assured that we will also discuss other solutions not involving the cloud. The beauty of Qubes Air, we believe, lies in the fact that all these solutions are largely isomorphic, from both an architecture and code point of view.

Isomorphic in this context means that, from the point of view of Qubes architecture, it does not matter whether your qubes run in RAM on this machine or they are completely different devices connected over a network. You design Qubes Air around the “cloud” but you can still use it in the same way on a single machine. It how you deploy that defines whether it’s a cloud or not, not the architecture. The linked article is about the architecture. To me, it has always been clear from the above wording.

This looks really scary indeed, because you forgot to make the other relevant part bold too:

it’s possible … without the user having to notice

doesn’t mean it’s the only possibility. You quote just says the same: “it will open many new applications” (which doesn’t imply that it will close existing applications).

I think you misunderstand what is said here. Indeed, it’s not expressed so clearly in this case, although in the context of other discussions, it’s clear to me. This is about a special use case: corporate deployment (see below).

No! Look, what do you think the main problem of Qubes OS right now is? Let me tell you: it’s the money! How do you get it? From the companies using Qubes OS and asking for support/development of new features. Many of them are really interested in secure computing, defense against ransomware, peace of mind when opening files from clients and so on. They are not interested in a local machine, where the user has full admin access. This is useless for them and also useless for the people working there who don’t want to administer the computers and only want to perform their own tasks. So in some sense you are right: the reason for Qubes Air is to make it possible to restrict the user access. Ordinary workers will not need dedicated machines from the Community-recommended list to run Qubes in this case. But please see above about the source code license and isomorphism.

This is exactly about the corporate use case. It does sound scary in the context of ordinary users and reminds the approach Windows has taken. However, there is no single example when free software with GPL was turned into such evil software as far as I’m aware. This is the whole point of the four freedoms! By the way, you ignored my question above about about it.

1 Like