Qubes OS could be honeypot?

I think you’re missing it: reproducible builds are how.

They can combine with open source to help us protect against compromise, defects, and malice. They would be a large step towards addressing your complaints - literally answering the question posed.

A fine start would be a large financial contribution to Qubes, to fund a dev or two, and get an enduring fix to issue #816.

I have no idea how far the core Qubes system is from getting there, nor whether it is an active area of work… be interesting to know.
I do know that it took a huge amount of time, effort, and energy to get reproducible builds working just in Debian Linux.

4 Likes

That post is 1 year old with 12 likes. Nobody took major offense or had a major issue with it. Chances are you’re misinterpreting my words.

Wasn’t implied.

But since you raise the topic… Depends on what you mean by hacker.

However, there’s a big market for vulnerabilities. References:

I don’t think I demanded that in my post. Citation required.

However, there is an issue indeed…

Quote security researcher and Qubes founder, Joanna Rutkowska - LoganCIJ16: Future of OS at 58:34 (at 58 minutes and 34 seconds)

The problem is, if you are a non-technical person, all of us can tell you our solution is the best. At the end of the day, you have no means of judging yourself because you don’t understand the technology, architecture. You just only judge whether I speak more fluently, or maybe David speaks more fluently, maybe he is a nicer guy because he does more jokes, or maybe I have bad looks or maybe, you are somehow, I don’t know, I am feeling, what I’m trying to say is just sorry, you don’t have means if you don’t understand technology to judge.

2 Likes

It’s a complex system.
The default images are loaded with additional, often unnecessary libraries and software, effectively going against attack surface minimization practices.
The security model fully relies on compartmentalization instead of taking a “defense-in-depth” approach and hardening individual components.
Supply chain attacks are commonplace. We can claim this is “speculation”, but the xz backdoor was done by a nationstate actor.
Organizations like Crypto AG, which were controlled by US intelligence, were trusted by many “professionals”.
There have been operations like “Operation Trojan Shield”.
When FOIA requests were submitted to various agencies regarding Qubes, the agencies provided nothing other than Glomar responses, instead of a simple “we have no relevant information”.
Theo de Raadt, from the OpenBSD project (which has it’s own issues - http://isopenbsdsecu.re/ - whether that site exists to manufacture uncertainty is up-for-debate), has, in the past, been critical of virtualization being an effective security control.
Qubes is often promoted by people that have a significant following on US controlled social media platforms.
Qubes is not being used by Chinese or Russian state-authorities (short of Snowden endorsing it, but who’s to say that Snowden isn’t a double-agent working from behind the enemy lines? That is, fairly common. Of course, that cannot be confirmed, without significant resources or insider knowledge.)
If Qubes were sufficient and trustworthy, instead of creating distributions like Kylin OS and Astra Linux, or even going so far as to move to in-house RISC-V CPUs & things like Elbrus (having full control over hardware supply chains is important and the public has become increasingly aware of side-channel attacks - Qubes does make people aware of these risks, which is a plus), why would they not just use it?

I suspect that people that are interested in using something like Qubes, are automatically within the crosshairs of those who are interested in spying on people.

You forgot the same was true for Gentoo, Tails, BSD, and even Windows Vista.

2 Likes

The FBI provided redacted documents regarding Tails, confirming that it is used internally.

I also find it very strange that library operating systems like MirageOS aren’t used where hardware isn’t needed and why hardened distroless-style templates aren’t used for for moderately complex services where library operating systems like MirageOS are sub-optimal.

;The default images are loaded with additional, often unnecessary libraries and software.

Business Implications:

Using minimal templates creates more support requests. More support requests mean more users giving up on Qubes because only a fraction of users create support requests, and an even smaller fraction receive resolutions to their problems.

More failing users lead to fewer users overall. Fewer users result in less donations, and developers need money.

“Qubes is often promoted by people that have a significant following on US-controlled social media platforms.”

Is there a language barrier affecting the promotion of security projects in the West, Russia, and China?

“Qubes is not being used by Chinese or Russian state authorities.”

If Russian authorities were to use Qubes, it could cause political issues due to geopolitics. For example, Russian Linux kernel maintainers were removed from the kernel, as discussed in this article

From Russia’s perspective, using Qubes, which is controlled by developers in hostile states, would be a liability. They simply don’t trust Qubes, and the open-source nature of the software does not alleviate their concerns, as a comprehensive code audit is considered impossible. Instead, they trust Astra Linux, which is developed locally.

I also find it very strange that library operating systems like MirageOS aren’t used where hardware isn’t needed.

This may be due to a lack of development resources; they need both the code and a skilled, trusted code auditor?

2 Likes

Qubes is based on Xen. Porting Xen to RISC-V (or any other hardware architecture) is a massive undertaking to say the least. (There’s some news that people are working on it so let’s see.)

Which RISC-V is really fully Open Source Hardware and available for purchase right now? I am not aware of any. All those with decent performance are combined with closed source hardware.

In-house development of fully Open Source Hardware is a totally different ballgame that would require astronomical amounts of hardware development expertise and funding. Full control over the supply chain is even less realistic.

This is just too much to ask for.

6 Likes

I wasn’t able to find them online. Could you provide a link to these FBI docs?

Интересные вещи обсуждаете господа. “Эльбрус” к сожалению производится на заводах в Тайване, а не в России, однако они хотябы контролируют то, как процессор работает на бумаге.

Это очевидно, Qubes полагается только на гипервизор на C, который уже 100 раз как “backdoored”.

The China is also developing own processors models, which is fully made in China. Check the Loongson models. They also has a own architecture for it.

В России просто не доверяют US/EU “security projects”. В Китае впринципе выход в свободный интернет ограничен, такие вещи как Tor и i2p просто не работают из коробки. Как и в России впринципе

Absolutely true!

Сейчас я бы лучше рассматривал то кого вы представляете в качестве атакующего на вашу систему, сейчас по сути существует 2 больших геополитических блока, это EU/US и RU/CN. Если атакующий из первого блока, используйте технологии второго и наоборот. Очень интересное обсуждение у вас тут.

Could you provide evidence for this claim?

Ахахаха, смешная позиция, вы столько времени использовали xz не подозревая бекдора в нем. То что я не предоставляю вам ZeroDay в программном обеспечении по первому вашему требованию, не обозначает что оно безопасное. Как же вы хотите чтобы я доказал это? Отправить вам PoC для обхода Xen гипервизора?

C это небезопасный язык, если у вас есть хоть минимальные технические навыки вы понимаете это. White House urges developers to avoid C and C++, use 'memory-safe' programming languages | Tom's Hardware. И дальше уже не важно используете ли вы гипервизор или нет. Проблема Qubes, что они полагаются только на гипервизор, и ни на что больше, никакой физической изоляции.

Unfortunately, in my world, an “argument by analogy” is neither an argument nor proof. Xen/QubesOS wasn’t affected by xz AFAIK. That doesn’t mean that supply chain attacks don’t exist. In fact, I never said that Xen is inherently invulnerable. I just wanted proof of your claim that it has been “backdoored” a hundred times.

Here’s another nice one, as you seem to be interested in analogies:

3 Likes

Я так понимаю по вашей логике мое утверждение о том что “Qubes has been backdoored a hundred times”, окажется верным только в случае когда это станет достоянием общественности? Скинуть вам PoC может еще?

Раз вы не принимаете “argument by analogy”. Исходя из ваших же утверждений, все безопасно, пока не доказано обратное, верно?

Ну и так же вы проигнорировали вторую часть моего сообщения

In my world, “true” would be shared truth. It’s something we could both agree on. I’m asking for facts, not truth. Anyone could claim that Xen/QubesOS is “backdoored” without providing evidence. That doesn’t mean the opposite is a fact (hard to bear, I know). I explicitly wrote that I never said Xen is inherently unbreakable.

There’s no doubt that C is considered unsafe. It has error-prone “manual” memory management, no garbage collection, and concurrency requires manual synchronization for threading. However, this does not prove that Xen/QubesOS has been “backdoored” 100 times. It doesn’t even support the assumption in terms of probability. That’s why I ignored it (and will keep doing this.) The design of a programming language says nothing about how carefully the (f)actual code was written or how many reviews it underwent. A VibeCoder can still mess up a lot with golang. An old graybeard who has done nothing else his whole life could write a perfect C program.

So, once again, please: Where is the proof that Xen/QubesOS has been backdoored 100 times?

1 Like

Ну в таком случае вы можете просто не соглашаться ни с одним из моих утверждений и это уже не будет “shared truth”. Ну и так же я не верю в вашу “shared truth”. Например в 1939-1945 жители Германии например что они “Лучшая нация”, вот у них была такая “shared truth”. Ой я забыл, вы же не любитель аналогий =)

Дизайн Qubes изначально построен на вере, что гипервизор не будет взломан. Я еще раз повторюсь, ВСЯ БЕЗОПАСНОСТЬ ПОСТРОЕНА ВОКРУГ ГИПЕРВИЗОРА НА C. Никакой ФИЗИЧЕСКОЙ изоляции данных Qubes не предполагает впринципе. Захват убогого гипервизора и все ваши данные как на ладони. На него еще переодически выходят PoCs, типо недавнего CVE-2025-27465.

Касательно этого, прямых докозательств у меня нет, однако было уже множество случаев когда в програмное обеспечение закладывали вредоносный код намеренно, как это было с xz, а так же ошибки при разработке как это было с MS17-010 EternalBlue. Но по вашей логике это ничего не доказывает.

Факт в том что мы уже имеем исторические примеры взлома програмного обеспечения с мешьшим объемом кодовой базы, а вся безопасность системы Qubes строится на предположении что гипервизор не будет взломан.

Thank you. As for everything else, how would you proceed? (I’m not referring to the German megalomania of the last century, where 15 years was considered a thousand, but rather the fact that even the hardware on which the programs run is not beyond reproach. The same goes for the users who operate these systems.)

Вынести критичные данные пользователя на физически отдельный хост, а не хранить их в гипервизоре. Сам гипервизор поставить за физический firewall, который будет контролировать выход в сеть. Qubes очевидно не предпринимает подобных попыток.

That would be another “Qubes approach.” :slight_smile:

At home, I do this air-gapping. (While still relying on Qubes OS for the clients.) It’s still quite impractical for traveling, though.

But just for argument’s sake: What software would you use for the firewall e.g.?

xcp-ng for hypervisor, alpine with custom routing rules for firewall/killswitch

Well, isn’t XCP-NG based on Xen? And again, just for argument’s sake: What language is it programmed in? How many lines of code does it entail? (Alpine wouldn’t count in the first place.)