Not restricted but shouldn’t be used, and limiting dom0 is not really good idea as I believe it could limiting “qubes configuration” too.
Limiting dom0 is a very good thing for your security and customizability. Dom0 has access to everything and runs a lot of code, so any malicious or buggy program in it can easily break all your security achieved with carefully crafted split-* qubes and other compartmentalization approaches.
Fortunately, dom0 already does not have to run the huge PulseAudio code (which doesn’t look very secure to me). Did you loose any customization because of that? I think it’s the opposite, because now it seems easier to replace it as a whole, whenever a good alternative appears. Similar arguments go for the sys-gui.
There can also be several “partial-admin” VMs instead, each managing its own subset of qubes. (It will will probably attract a lot of business customers to Qubes, too, benefiting every user.)
Why do you need any control over dom0? Especially when it doesn’t do anything? I guess, it can make it even easier to replace it? Isn’t it more control?
Which function and why do you need it?
For the same reasons I want control over my car and I don’t have it, because its “dom0” is in someone else’s laptop and I have to pay for the diagnostics and repair, even if I could do it myself if it was mechanical?
I can’t explain it more banal than this.
Well, maybe having to pay for replacing mobile phone battery today unlike couple of years ago is more banal, I admit.
Instead of educating users, we’re continuously (and intentionally?) dumb them down - “you’re stupid, this is too complex for you, so we will hide it from you” politically correct wrapped in a wafer “we will make it easier for you”
Please don’t deny this as at least a possible legit perspective.
2 Likes
I completely agree that control over everything you own is essential. This was not the reason I asked. I meant, which control you are loosing when making dom0 minimal? AFAIK you still can do everything you could before; it just gets compartmentalized.
Would you also say that you lost control over the Linux kernel running in dom0, because it doesn’t have access to everything? (compared to an ordinary Linux distro) (some things are managed by Xen instead)
Thank you for this.
From the diagrams and the available documentation, it is obvious that tomorrow dom0 will have it’s own IP address and God knows which servers. Sounds familiar?
So, it’s not about minimalism (I can’t agree more with it), but about the topic subject.
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.
1 Like
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
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.