See also:
2 Likes
An important difference between minimal templates and dom0 is that minimal templates’s AppVMs are expected to have contact to user data, which greatly increases the risk that some package’s binaries will be executed, either intentionally or inadvertently.
As you know, dom0 can contact every data and can execute every binary in every VM. Also, a malicious package can contain no binary, e.g. it can simply replace config files with others, which would affect the way non-malicious system processes work, thus creating a mess. Things can be even more nuanced. An attack doesn’t necessarily mean data exfiltration.
If a user follows the recommendation of not using dom0 for anything but configuration, e.g. no viewing your screenshots there - send them to a dvm
The software generating the screenshots is installed as trusted in dom0. The input data (the workspace) is fully accessible to dom0 (it generates it). Therefore, the output image file has the quality of ultimate trust. So - trusted data, trusted software in the only fully trusted VM. If such data can “activate” malware, then any other data existing in dom0 can do that. Why should one send ultimately trusted data to a disposable VM - a technique aimed for untrusted data? If that is not a security theater, I don’t know what is.
no using it as a vault for your secrets - use the vault qube
Secrets are also ultimately trusted data. The purpose of having a vault domU for them is not to protect the secrets from activating malware in dom0, but to protect the secrets from less trusted domUs.
then the risk of a potentially malicious package in dom0 being “activated” through some user data being processed, is much lower than in the AppVMs based on minimal templates, because the latter do have regular contact with often at least somewhat untrusted user data. Given this important difference, no I don’t think the latter are “security theater”.
The whole idea that malware can safely exist in a passive state in dom0 and that the whole security of dom0 depends on the user being extra careful not to activate something somehow, while updates can install any new executables, including ones not explicitly requested by the user, is exactly what you don’t think it is and against all the recommendations related to that.
And why would it do that? The point I was making was about user data being processed inside a VM, such as a user opening a malicious PDF file. If the user follows the recommendations about not processing user data in dom0, how would dom0 start processing data in some AppVM by itself?
IIUC this only applies if you didn’t set up a sys-gui, which is where the QubesOS project is headed.
That does not follow…one kind of exploit being possible does not mean all other exploits become possible. The data in this case would be the specific configuration of visible GUI elements, and their content, of some VM, while the exploit would be some bug in the code that processes that data to produce the screenshot file. Let’s say there is such a bug and such data can be crafted; how does that equate some other data that has nothing to do with screenshots “activating” something?
Because viewing and editing an image file uses different packages with different code than taking the screenshot. The goal is reducing exposure: there is a difference between “only” running xfce4-screenshooter on some user data and running it plus ristretto, gimp or whatever else with that user data. Ultimately, as stated, the goal is to remove even the exposure to xfce4-screenshooter as well, which is one of the advantages of sys-gui (at least potentially; I haven’t checked exactly the implementation).
Except you will likely be processing those secrets in some way, which may include some kind of database software, editors beside vi or use gpg on it or even apps like ristretto in the case of secret images, keepassxc to conveniently organize some types of secrets etc…plus there will be the issue of getting those secrets into dom0, which means even more exposure to user code.
- Where is the dom0 malware?
- Where did I state that “the whole security of dom0 depends on the user being extra careful not to activate something somehow”?
- How does the post you link even relate to updates at all? None of the package you listed have entries in qubes-updates. If you mean upgrade, e.g. from 4.1 to 4.2, then that is still not executing the packages themselves, but running their installation scripts. I was making a point about package code getting executed, intentionally or unintentionally, by user data.
2 Likes
The point I was making was about user data being processed inside a VM, such as a user opening a malicious PDF file.
But we are not discussing this in the current thread.
IIUC this only applies if you didn’t set up a
sys-gui, which is where the QubesOS project is headed.
As long as it is “headed” and not “arrived”, we are in the exact case I described.
That does not follow… […]
Consider what was said in its context, not in a newly presented one. By “any other data” I mean any data with the same security qualities of the screenshot, i.e. ultimately trusted. I was not discussing bugs, neither were you. You talked about activating malware and I replied to that.
Because viewing and editing an image file uses different packages with different code than taking the screenshot.
ImageMagick is installed in dom0 (not by me). It was a dependency in 4.1.2. It is not a dependency in 4.2 but the upgrade did not remove it. It is obviously considered trusted, so what I said previously remains. Also, consider what was discussed earlier: either all or none packages in Fedora are trusted. There is no documented criteria on how to distinguish trusted, trustworthy or other sub-categories or trust or distrust. If there was, and if that was explained, there would be no confusion and the current thread would not exist.
[…] getting those secrets into dom0 […]
I am not considering such scenario at all.
- Where is the dom0 malware?
You said “potentially malicious package in dom0”. I guess you know better. To me it makes no sense to assume malware is trusted software and vice versa. As explained in the OP, I don’t understand how it is possible to trust something as a whole while distrusting its parts.
- Where did I state that “the whole security of dom0 depends on the user being extra careful not to activate something somehow”?
The whole security model which you described is based on that concept/recommendation.
None of the package you listed have entries in qubes-updates.
If you mean upgrade, e.g. from 4.1 to 4.2, then that is still not executing the packages themselves, but running their installation scripts.
How do you think libs are used?
I was making a point about package code getting executed, intentionally or unintentionally, by user data.
How can data execute code?
It is not present in a clean install. Turns out I needed it for something.
GraphicsMagick is in the default install, it’s needed by qubes-core-dom0
As it happens one of the ImageMagick programs (“convert”) is needed by the scripts that let you add labels (colors). I really only needed that one, but had to install the whole suite just to get it. If I knew of a saner alternative, I’d use it instead.
I think this will be my last reply here, as this thread is a total waste of time and it seems more and more that you’re just interested in spreading FUD.
I don’t care what you think we’re discussing. You asked a question “But why Fedora?”; the question was answered. Evasion is not an argument.
Wrong. You can set up a sys-gui today if your threat model requires it; should you choose not to do so or can’t for whatever reason that’s your problem. It also shows that things like screenshots being processed to some degree in dom0 (namely generated) is considered to be an issue and a solution is already here, albeit still experimental for the time being.
How about you consider my argument instead of evading again. I said:
You replied:
So you’re making the claim that because specially crafted GUI content could lead to a compromise when processing it with xfce-screenshooter (true, albeit very unlikely), other data in dom0 can also lead to a compromise. This is a non-sequitur. I also never affirmed your further incorrect assertion that the screenshot data is ultimately trusted. You just made that up and it’s obviously not true; a lot of data in dom0 is not ultimately trusted, in fact, especially as long as “minimal dom0” is not implemented.
As to “malware” vs. “bugs”: this doesn’t matter much; if the “bug” can be used in an exploit then it’s a problem, whether it was intentionally planted or not.
Wrong. None of the devs would recommend you use ImageMagick in dom0; the installation of ImageMagic is trusted, but not its execution, especially with arbitrary data. It’s also obvious that the Qubes team does aim to eventually get rid of packages such as ImageMagick from dom0. Just because they haven’t fulfilled your wishlist of issues doesn’t mean they’re not eventually going to get to make progress on things like this.
Wrong. This has not been demonstrated. What is trusted is the installation of any regularly distributed package from the standard repositories (i.e. not NPM or PiPy and the like). Further, the execution (usage) of some packages is trusted out of necessity. And even here the devs actually try to minimize to some degree the amount of trust required by removing at least some unnecessary packages and choosing EOL versions.
Wrong. I have explicated this with direct quotes from the documentation and it didn’t take a linguistics degree on my part to do it. See my above post. And I’ll just add that just because something isn’t made explicit, doesn’t mean it’s not being explained. Would it be better if it was made more explicit? Sure, but the docs definitely help in understanding these concepts.
Another evasion. I asked because I want you to specifically tell me e.g. how dom0 having access to all AppVM user data is going to lead to a compromise. I’m not getting any clear arguments from you.
It’s been explained many times now. Installation of a package vs. usage of that package.
Wrong. I never talked about dom0 security in general or QubesOS security in general in this thread. This is a straw man. And it’s kinda funny, because if I did you’d probably accuse me of going off-topic. The main security feature of QubesOS is isolation. Not treating dom0 as a monolithic Linux where you put all your data and do all your stuff is part of that, but it’s absurd to consider this an accurate description of the overall scheme.
Regarding your new links: the first is just a repost of your previous content, except now on GitHub instead of the forum; how does posting the same stuff over and over again add to the conversation? This is evidence that you’re trolling.
The second is basically an extended version of the first, so also no new argument. It has been said many times in this thread now that there is a distinction between installation and usage. I’ll not waste time going over that again. Read your own thread.
What do libraries have to do with it? New package versions will generally come with new static libs, if any, while, given the big gap in Fedora versions between QubesOS versions, many shared objects will also be updated. But just because something new is getting installed, doesn’t mean all its functions/methods are getting called with an endless stream of arbitrary data or at all. I also said above that I can’t fully evaluate how reasonable the Qubes team’s trust in the installation process is, but I’m pretty sure they know a whole lot more about IT security than both you and me and the reasoning that installation does not equal full use of the package is sound. I’m not aware of any standard Fedora package having infected anyone via installation alone and your attempts to provide examples have failed.
Oh no, you got me! I’m totally defeated…sigh…what I obviously meant to say was user data getting processed by some code inadvertently or intentionally when the user is handling that data…there are many ways this can happen.
3 Likes
Agreed on both counts.
Many of OP’s posts seem to follow this pattern.
1 Like
There were some really good points made in this thread, besides the core issue of using Fedora; I’m referring the Proxmox alternative to Xen, the useless weak dependencies installed in Dom0, the general InfoSec stance and maybe others which I don’t recall.
Calling this FUD just aligns with the rest of the general attitude of “these are my toys, I do whatever I want with them” around Qubes development.
2 Likes
+1
I appreciate @Bearillo 's responses, and @qubist 's questioning of central tenets of QubesOS architecture. I think @Bearillo gave satisfactory answers, and I think I got what I wanted from this thread.
Yeah, sometimes I get a glimpse of this attitude–no, the word “tendency” is more appropriate here–especially on topics around dom0 distro choice, and passwordless sudo.
2 Likes
you’re just interested in spreading FUD.
Thank you for the unsolicited (and unsuccessful) personal analysis.
I don’t care what you think we’re discussing.
Thanks for confirming it directly.
You asked a question “But why Fedora?”; the question was answered. Evasion is not an argument.
I did not ask that question. That is the question from the docs which I quoted in the thread title. My actual questions are in the OP’s end and they are about something much more than it (if you care at least for a moment to know what you are discussing).
Wrong. You can set up a
sys-guitoday if your threat model requires it; should you choose not to do so or can’t for whatever reason that’s your problem.
Facts prove the opposite.
How about you consider my argument instead of evading again. I said:
How about starting to care what the discussion is about? I don’t need you to read back to me what I have already said, especially if you fail to follow your own way of introducing unsound arguments.
So you’re making the claim that because specially crafted GUI content could lead to a compromise when processing it with
xfce-screenshooter(true, albeit very unlikely), other data in dom0 can also lead to a compromise.
No, I am not making that claim - you are, and I am not the one “spreading FUD” that viewing a screenshot (ultimately trusted data) using trusted software can result in “activating” sleeping malware, lurking in other trusted software.
This is a non-sequitur. I also never affirmed your further incorrect assertion that the screenshot data is ultimately trusted. You just made that up and it’s obviously not true; a lot of data in dom0 is not ultimately trusted, in fact, especially as long as “minimal dom0” is not implemented.
I agree that the way you represent things is a non-sequitur.
A screenshot generated with trusted software is ultimately trusted user-viewable data. So is any text document you type yourself. And yes - it is a security theater to do something like having vim installed and deliberately avoid using it (by using vi) for the purpose of not “activating” hidden malware in it. That’s what I explained. And that does not need affirmation, as it is directly observable fact.
As to “malware” vs. “bugs”: this doesn’t matter much; if the “bug” can be used in an exploit then it’s a problem, whether it was intentionally planted or not.
Malware and bug are different things. Bug and vulnerability are also not always identical. That does matter much in the context of trust (which is the core of the current thread, whether you care or not).
Wrong. None of the devs would recommend you use ImageMagick in dom0; the installation of ImageMagic is trusted, but not its execution, especially with arbitrary data.
I wonder if you realize what you are talking about.
-
ImageMagick (+libs) was installed as a dependency by the devs, i.e. explicitly trusted by the devs. This means these same devs, who (according to you) do not recommend using it, actually use it for processing your data. That’s why I asked whether you understand how libs are used.
-
There is no censor controlling which data processed by it is arbitrary or not. ImageMagick is just trusted, installed and that’s it.
Now, reread your own statement and consider whether you are “right”.
It’s also obvious that the Qubes team does aim to eventually get rid of packages such as ImageMagick from dom0. Just because they haven’t fulfilled your wishlist of issues doesn’t mean they’re not eventually going to get to make progress on things like this.
This discussion is not about what may happen in indefinite future. It is about how one should understand the choices made, what they mean and how to follow documentation today. It is not about criticism of the choice but about understanding it. Trying to belittle the attempt of one to understand the deeper basis of things by reducing it to “fulfilling a wish list” (as if it is some caprice) is somewhat cynical.
Wrong. I have explicated this with direct quotes from the documentation and it didn’t take a linguistics degree on my part to do it. See my above post. And I’ll just add that just because something isn’t made explicit, doesn’t mean it’s not being explained. Would it be better if it was made more explicit? Sure, but the docs definitely help in understanding these concepts.
Considering the way you invent things which were not said and twist things which were said, I am not surprised with you satisfaction of the unwritten.
Another evasion. I asked because I want you to specifically tell me e.g. how dom0 having access to all AppVM user data is going to lead to a compromise. I’m not getting any clear arguments from you.
Why should I provide arguments about something which was not even stated by me? You refer to the docs but have you actually read them?
“There’s only one admin qube, and it’s called dom0. You can think of it as the master qube, holding ultimate power over everything that happens in Qubes OS. Dom0 is more trusted than any other qube. If dom0 were ever compromised, it would be “game over.” The entire system would effectively be compromised.”
You talked about:
the risk of a potentially malicious package in dom0 being “activated” through some user data being processed
This is about malware, not about bug, not about vulnerability (3 different things).
Then, I explained it was a security theater to assume that such malware could reside in an inactive state in dom0 and the user could avoid it by superficial measures such as using vi instead of vim (both installed), or by opening ultimately trusted data in a way suggesting it is distrusted data.
You suddenly asked:
- Where is the dom0 malware?
and I said you should not better, meaning - unlike you, I don’t assume I know what others are thinking, unless clearly stated. The only thing which was clearly stated is that you consider the possibility of malware in trusted software inside dom0. And when I pointed that out, you said I was “interested in spreading FUD” and you insisted that I am evading some argument.
What do you actually expect? A detailed description of how malware residing in dom0 can compromise data on the rest of the system? Why do I owe such explanation?
It’s been explained many times now. Installation of a package vs. usage of that package.
And it has been explained (not evaded) in a reply that it is not possible to isolate the latter in a guaranteed way within the same VM. If it was, minimal templates would make no sense whatsoever.
Wrong. I never talked about dom0 security in general or QubesOS security in general in this thread.
Who said anything about “security in general” or “QubesOS security in general”? This is yet another example how you invent things which were never said, thus twisting the whole thing and marking it as “wrong”.
You represented specific security model in a specific context - the user taking care not to activate potential malware in trusted software residing in dom0. That’s the only thing I addressed in my followup. Instead of accusing others of non sequitur and straw man, better please try to read carefully and follow (including your own words).
Regarding your new links: the first is just a repost of your previous content, except now on GitHub instead of the forum; how does posting the same stuff over and over again add to the conversation?
How does repeating “wrong wrong wrong” and “evasion evasion evasion” add to it?
Never mind, I will answer. It is:
- a reply to your faulty search inside closed GitHub issues
- a reply to your question 3 which assumes that upgrade doesn’t include update
- it also shows that someone has taken the time (so you don’t have to waste yours) to actually bring that to the attention of the devs, who can do something about it, as well as how it is handled further, in case anyone is interested
- it also assumes you are intelligent enough to associate these things with each other.
This is evidence that you’re trolling.
I am not the one who attacks others on a personal level and who openly states that he doesn’t care what the discussion is about.
What do libraries have to do with it?
If you can actually look into what I asked you, you will know. In this particular case - yes, I am deliberately evading further discussion about it because it is way off-topic.
I’m pretty sure they know a whole lot more about IT security than both you and me and the reasoning that installation does not equal full use of the package is sound.
Anyone is free to be sure about whatever gives comfort. That doesn’t mean nobody else should ever question or try to learn anything, or that one deserves to be attacked for doing so. Critical thinking is different from criticism. We are discussing technical things, not religious ones which should never be questioned but only chanted.
I’m not aware of any standard Fedora package having infected anyone via installation alone and your attempts to provide examples have failed.
“I am not aware” != never happened != happened but never detected != impossible to happen.
Agreed on both counts.
Many of OP’s posts seem to follow this pattern.
I have always had a positive and respectful attitude to you, but in this particular case I dare to say that one should sometimes get off one’s high horse. If for some unknown reason you have anything against me, feel free to attack me in a PM, rather than “contributing” to the thread with personal remarks against forum rules. Thank you.
I apologize for the lengthy reply and for going off-topic myself. I just wanted to be clear on all points, as I have been accused of evading some. In other cases I have been accused of being overly terse which to some sounded “brusque”. I guess there is no way to satisfy everyone.
1 Like
The problem is not that there are no legitimate points in this thread, or that there is not legitimate debate to be had about Fedora/Xen. The point is that the way OP engages with people. Debate should be about coming to accurate conclusions about reality and an understanding of the similarities and differences between the values and judgements of respective parties. OP’s comments are combative, as if this was a contest to see who “wins”.
That said, it’s not really fair to assume anything about OP’s intentions. But I don’t really care about intentions in this case. I do care about intentions when dealing with some individual incident, but I care more about consequences when dealing with a stable pattern of behavior over time.
It’s also fair to say that mere statements of judgement are not particularly helpful, but constructive criticism would be. If OP is well-intentioned then the feedback could lead to a more harmonious community. If they are not then it could help lurkers.
Individual people have agency. They deserve to decide how they want to spend their time and energy. QubesOS is released as free software, meaning that anybody - including OP - can take their work and do whatever they want with it. Change dom0, move to a different hypervisor, make all of the borders glowing neon lights if they feel like it. This is literally the exact opposite of “these are my toys, I do whatever I want with them”.
2 Likes
AFAIK it doesn’t work for some people, depending on hardware/configuration. Moreover, this is completely irrelevant. Your demand of the perfectly cleaned dom0 is somehow misplaced. These problems are officially considered as security bugs, which your link confirms. Their severity we can discuss (it’s one of your valid questions; I disagree that it’s sufficirently severe to call it a “security theater”). Qubes devs do not have infinite resources to fix everything. Help them if you actually care about it that much so you’re spending a lot of time claiming that it’s so important.
How about you repeat your arguments in a more clear and concise way (e.g. as a list), if people who actually care to write walls of text to you don’t get them (me included, sometimes)?
This might sound paradoxical on the surface, but if you think about it, it indeed works like this, as far as I understand. Dom0 can contain untrusted packages, which you never run. Please provide us a plausible way how this situation could result in an owned system. Related bits of data are never read or executed. It’s the same as the inter-VM text copy: it actually goes through dom0, but is never parsed there.
I’m not sure that a screenshot is “ultimately trusted data”. It can contain almost any bit sequence, depending on what VMs show, some data could exploit a potential vulnerability in untrusted software in dom0 (only if you run it!), at least in principle. I don’t understand why you call all software in dom0 “trusted”. It’s not, which is what this topic is about AFAIK. Official Issues like one I linked confirm this.
Any text document you type yourself could absolutely contain a bit sequence that triggers a vulnerability somewhere if you parse it. Do you need examples? This is why the less apps you run in dom0, the better, including avoiding vim.
Having said that, it’s very, very unlikely that such vulnerability would actually own dom0, since it would have to specifically target Qubes OS (and correct release, too).
It matters very much. As I explained above, a bug (even if triggered) would not try to attack dom0 or download malware in Templates. Malware might.
Wrong. Installation script of ImageMagick was executed in dom0 and is trusted. The app itself isn’t. These are completely different pieces of code, including their length.
There is nothing in dom0 which runs ImageMagick, unless you do it yourself. Code which is not executed will not do anything.
At this moment, there are security issues with software installed in dom0, as confirmed by open Issues. Until it’s fixed, don’t run anything in dom0 if you can. It was explicitly said by devs many times. What’s unclear here?
This is indeed how I understand it, too. You should now explain why you think “this is security theater” by providing us a plausible path to the vulnerability being executed and taking control over dom0. I have no idea how it can happen if you don’t run untrusted software in dom0 yourself.
Because you yourself are claiming that such software residing in dom0 quietly is a security theater. This is a strong claim without any reasoning, i.e., FUD by definition.
Could explain again please? I don’t understand why you can’t isolate them.
You are right that it is possible. It’s better to have as few installed packages in dom0 as possible. There are open Issues about this, so the devs confirm it, too. However, severity of this problem is low, because there are no known cases of such malware (again, as I explained above, simple bugs would not be sufficient here).
2 Likes
I see your point, and I am not going to dispute belief. If you BELIEVE that Qubes is safe as it is, it’s ok with me, because this is on a religious level. I’m not going to challenge religion!
If we are talking about rational arguments, the way one poster writes or another poster replies is inconsequential. The essence is the idea , the arguments, the objective truth and reality.
Your demand of the perfectly cleaned dom0 is somehow misplaced.
It is not my demand. It is what the documentation asks the user to do, resulting in the confusion explained in the OP.
Help them if you actually care about it that much so you’re spending a lot of time claiming that it’s so important.
If and when I can, I will surely try to. If there is info what actual help is welcome, that may make it easier. Otherwise repeating “no resources” is not welcoming help.
How about you repeat your arguments in a more clear and concise way (e.g. as a list), if people who actually care to write walls of text to you don’t get them (me included, sometimes)?
How about people read the OP and focus on it instead of asking me to repeat? I have repeated more than enough and my resources are not unlimited too. If something is unclear - ask directly. It is that simple.
This might sound paradoxical on the surface, but if you think about it, it indeed works like this, as far as I understand.
And I want to know how exactly it works. How do you mix dirty water with clean water and receive clean water?
Dom0 can contain untrusted packages, which you never run.
That is the opposite of what the docs say.
Please provide us a plausible way how this situation could result in an owned system.
Why should I do that? I did not write the “game over” docs. Ask those who did.
I am only willing to know what are the criteria and procedures for trust. I wonder how many times I have to repeat it.
I’m not sure that a screenshot is “ultimately trusted data”. It can contain almost any bit sequence, depending on what VMs show, some data could exploit a potential vulnerability in untrusted software in dom0 (only if you run it!), at least in principle.
Who is spreading FUD now?
I don’t understand why you call all software in dom0 “trusted”.
I don’t call it anything. I refer to what others have said about it.
Any text document you type yourself could absolutely contain a bit sequence that triggers a vulnerability somewhere if you parse it. Do you need examples?
Yes, I would like to see an actual example which shows how using vi instead of vim to open a text file can protect from something bad lurking in vim. Then, if such example exists, I need to know why vim is installed in dom0. I would also like to know how one is supposed to know in which package exactly such bad stuff may be hiding, because it can be that it exists in vi and not in vim.
This is why the less apps you run in dom0, the better, including avoiding vim.
user@dom0:~ > ps axf | wc -l
546
user@dom0:~ > dnf list --installed | wc -l
1254
Meditate on this in relation to what you said. Then let me know what makes sense and what not.
Having said that, it’s very, very unlikely that such vulnerability would actually own dom0, since it would have to specifically target Qubes OS (and correct release, too).
On what basis do you assume that it is very very unlikely Qubes OS to be targeted? Is that unlikeliness a solid basis for assuming security? If it is, then we may be even with VMS - it is even less likely to be targeted, hence more secure.
Wrong. Installation script of ImageMagick was executed in dom0 and is trusted. The app itself isn’t. These are completely different pieces of code, including their length.
Explain how libs are used.
There is nothing in dom0 which runs ImageMagick, unless you do it yourself. Code which is not executed will not do anything.
Explain how libs are used.
At this moment, there are security issues with software installed in dom0, as confirmed by open Issues. Until it’s fixed, don’t run anything in dom0 if you can. It was explicitly said by devs many times. What’s unclear here?
If you don’t “run anything” in dom0, you can’t even boot. So, what is “run” and what is “anything”, considering what I said above?
This is indeed how I understand it, too. You should now explain why you think “this is security theater” by providing us a plausible path to the vulnerability being executed and taking control over dom0.
You are asking me to explain what I think through something I don’t think. I cannot do that. I can only explain the former:
It is a security theater because such “careful” behavior does not ensure security. It basically means holding one’s breath and distrusting one’s own moves in order not to do something to a machine which is supposed to serve the user, not the other way around.
Because you yourself are claiming that such software residing in dom0 quietly is a security theater.
No, I am not claiming that. I am claiming that it is a security theater to consider that this is possible and the proposed way to guard oneself from it.
Could explain again please? I don’t understand why you can’t isolate them.
Because this is not 16-bit MS DOS but a complex system where many processes run in parallel and trigger other processes. Execution of a binary code does not happen only by explicit user activity, e.g. by typing “vim” on the command line and pressing Enter. Again - how are libs used? How about drivers? Do you manually “run” the driver? How does a computer boot? Think. I may be wrong as usual (and getting better at it).
Debate should be about coming to accurate conclusions about reality and an understanding of the similarities and differences between the values and judgements of respective parties. OP’s comments are combative, as if this was a contest to see who “wins”.
Consider the way the OP is often answered and the possibility for discussing anything deeper than “How do I do ?” If deep questions are answered in a shallow way, what is the OP supposed to do? To never try, so that the status quo is happy? To never question? How do you approach reality without questioning?