Qubes-Air? Qubes in the cloud?

It’s the best currently available tradeoff. Because Joanna, or some documentation, said that they would like to write their own (meta)OS from the scratch but it’s not feasible considering resources. I’m sure you can recall this.

Please cut the FUD. No one is trying to move your dom0 into the cloud against your will or any nonsense like that. The Qubes OS Project has always been a user-first, security-first project. Nothing about that has changed. Spinning inane conspiracy theories about one of our own 4.5-year-old articles accomplishes nothing constructive. If doing right by users for over a decade hasn’t earned us any goodwill in your eyes, then nothing we say will dissuade you from assuming the worst.

2 Likes

Also: It’s open-source software, remember? No one can ever stop you from creating your own build that lets you do whatever you want.

Heck, you could even fork the entire project and call it “Non-Evil Qubes (NEQ)” if you’re convinced that the rest of us are trying to be evil. If your fork is the superior project, surely the majority of contributors would abandon the old one to join yours.

1 Like

14 posts were split to a new topic: Moderation policies

Already addressed misconceptions about Qubes Air in detail in this other thread:

1 Like

I don’t think there is any point in asking the question in OP post for now as there is no active development of Qubes Air architecture. Right now it’s just the development of induvidual blocks like sys-gui that could be used for Qubes Air later. But as I can see there is no development of Qubes Air architecture going on and Qubes Air for now is just a general thoughts on the topic without any definitive development plan existing.
So nobody can tell right now what will be with dom0 in the future.
In the future it may have restricted functionality because of different reasons for example disabling some functionality for security reasons or just because developers didin’t have time yet to make interface to securely access some functionality in dom0 like it is with Xen and CPU cores temperature right now:

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

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

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.

There’s so much to read.

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.).

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

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.

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.

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.

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)

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

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

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

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