Qubes OS could be honeypot?

General Discussion
108

Interesting discussion.

Basically open-source software can be vulnerable to supply-chain attacks… so, when it comes to QubesOS you want to watch out for backdoors in Fedora, Xen and Qube-tools. Debian, Whonix and community provided distros are less critical as long as an attacker does not have a zero-day for Xen. For HVMs qemu increases the attack surface.

When you decide to download Tails your IP might be recorded without the tails-maintainer knowing.

Anyway… check your traffic with wireshark and let us know who talks to your backdoor or your backdoor is talking to.

109

Anything can be a honeypot if one doesn’t know what a secure version of a honeypot looks or acts like or what to look for but the only danger I can see would be to those who know nothing about what a secure OS and network connection looks and acts like but that would apply to any network security measure one might apply on a whim.

“Bad actors” don’t need honeypots because there are more than enough…shall we say, less-than-intelligent people(?) to satisfy any number of crooks.

Qubes-OS is currently and sociopolitically “popular” for reasons that have nothing to do with network security. As it is, it appears pretty secure but doesn’t qualify as a daily driver for me. At least, not yet. On the other hand, it could be useful, (though not necessary) along with other tools, if something should happen and I find myself in need of some sort of long-distance, snail-mail level privacy for something so I’ve installed it on a USB stick and will keep it up to date.

110

Traffic lights and crosswalk are given to you to securely cross the street. But you cannot ask from the givers to guarantee no car will hit you when crossing the street there. It’s up to you to ensure safe crossing.
Same with Qubes.

1 Like
112

LOL
“Honeypot” or not, Qubes is brilliant and great fun!

113

I see the US Gov. coming up much regarding honeypots, which makes sense given they are seemingly at the forefront of the surveillance state vision (second maybe only to China???). Since that is the case, why don’t we all start a fund to pay a lawyer or someone familiar with Freedom Of Information Act requests that can help make such requests in relation to Qubes?

From my very limited understanding of FOIA at least, even if something were classified and thus heavily redacted or denied due to national security concerns for example - would that not then be some indication of a program? Further, I can only assume that such a vast honeypot program would have so many items involving various agencies and such, that there would have to be a hit somewhere along the line.

Idk, seems like a reasonable way to check some of these concerns? :smiley:

114

Interesting, I just did a search for “FOIA Qubes OS” and this popped up. Looks like someone had a similar idea:

Maybe something for everyone to follow. I still think it would be cool to fund additional requests going forward, like an annual FOIA or something. Or on more specific information regarding Qubes that would have the potential for more hits.

My thought from this came from a Netflix documentary series “Web of Make Believe” about Daniel Rigmaiden. He made FOIA requests about a technology he suspected was responsible for his capture and exposed the Stingray devices we all know today.

3 Likes
115

Looks like there are several actually. FBI and CIA have denied the request :confused: and can “neither confirm nor deny” such records exist.

2 Likes
116

SELinux is NSA

117

Yeah, if a device has any membrane or surface that will vibrate in resonance with sound waves (i.e., the LCD in smartphones or laptops) - circuitry on the motherboard could pick up those vibrations, send them off to cloud for signal processing. Smartphones have enough vibration, etc. sensors built-in.

Like the old Cold War trick of picking up window glass vibration with a laser beam - on steroids :slightly_smiling_face:

118

This question is not unreasonable, and I wish to answer it, even though I am months late.

First, by virtue of its promises, Qubes is a target of malicious interference. Even if it is not purposefully a honey pot, it is a de facto honey pot by attracting the kinds of people who become interesting to those capable of malicious interference.

Second, Windows is completely compromised %$^$%. If you had to chose between Windows and Qubes, there’s no contest about which is more secure. Apple is probably secure enough for most people, and much easier to use, and WAY MORE EXPENSIVE. If you prefer promises made by people you don’t know in shiny corporate offices, choose Apple.

Third, even if QubesOS is a honeypot, most of the most interesting targets use Windows and Apple products and smartphones. QubesOS is not uniquely a target, or even especially an important target. Paying the least attention to the news, we find big names compromised not via QubesOS but through their smartphones.

Fourth, compromise is not all or nothing. If we can trust the vulnerability reports, Xen is pretty solid. Qubes is pretty solid. It’s not easy to compromise these solutions. For the most part they are secure. Exploits for Qubes are expensive compared to others. Consider the price of zero-days for the iPhone versus Android. Android exploits are cheaper because iPhone is more secure. I feel confident at least that if my machine is compromised, it cost somebody a few hundred thousand dollars at least. And then they will find… not much of interest, because…

Fifth, we should never trust a networked computer system with the keys to the kingdom. If you have serious security concerns, you should be taking non-Qubes steps to mitigate those risks. Qubes is just one part of a security regime, each step adding one more plate of protection. I have multiple machines for different tasks. One is dedicated just for instant messaging over Tails. Another airgapped machine is reserved for personal stuff I don’t want on the network. I have a Winblows machine off the network as well for playing some games. I store everything on separate encrypted drives which are mounted on a need-to-access basis. The cost of compromising me is probably in the millions, and what will they find? Probably nothing of interest. Some of us are just paranoid and love to play with these kinds of toys. We love to imagine we’re sticking it to the system, even if we’re not. Because…

Sixth, at the end of the day, nobody knows. Nobody on Earth can audit every line of QubesOS code. Nobody can know what this or that government or criminal organizations (are they the same thing?) can do. If you want it to be so, the universe can be vulnerability turtles all the way down, in which case QubesOS is just another trick. Given the history of Murder Inc, it probably is. But I like tricks, especially costing Murder Inc. at least 1 million a pop. Let them come and, as you say, crack luks2. Shit, I’m still running luks1 on some drives. Gotta get more paranoid ASAP and pump those rookie numbers up.

Finally, while Qubes pleases me by giving me a “reasonably secure” OS, what really makes me excited about being part of Qubes is the operating system itself.

  • It has changed the way I do things. It has taught me things I didn’t know before.
  • I like the fact I can install a bunch of junk in one VM and it has no bearing on another. I just installed npm in a VM, which includes this huge bundle of JS libraries. It doesn’t touch my other VMs.
  • I love not having a host OS, and not worrying about how dirty it has become, or the anxiety about when to reinstall, and everything I’m going to lose. With Qubes, I’ve already factored all that in. I know what’s supposed to be in each Qube. I’ve set up my own system to keep track. I write scripts to install the things I need.
  • I especially love not opening questionable files (like JS encrusted PDFs) in networked machines. Whatever I download, I move to non-networked vaults. From there I can use the USB utility to move it off the machine, or open it in a disposableVM.
  • I love running Whonix on Qubes! I love everything running through Tor, without any concern about DNS leakage or other annoyances! And it’s a default VM.

So for me, QubesOS is about the experience. I love it!

5 Likes
119

Qubes OS could be honeypot?

Could be. But why only ask about Qubes OS?

Debian, Fedora, Qubes, you name it could be honeypot?

Could be. Could either be a honeypot (which assumes that developers are malicious?) or could be compromised by a backdoor.

Is it possible to prove that there is no backdoor in you-name-it? No.

But Open Source helps? Yes, but at the moment that is insufficient.

Threat Model

The primary concern is the potential for widespread compromise through the distribution of malicious binaries. This threat model assumes:

  1. Sophisticated attackers with significant resources (nation-states, well-funded criminal organizations).
  2. The ability to compromise one or more core developers or their systems.
  3. The goal of inserting malicious code into widely-distributed binaries.
  4. The inability of most users to detect such compromises due to reliance on pre-built binaries.

Key Threats

  1. Supply Chain Attacks: Compromising the build and distribution infrastructure to insert malicious code.
  2. Developer Compromise: Exploiting or coercing core developers to introduce backdoors.
  3. Hidden Malicious Code: Inserting malicious code that doesn’t appear in the public source but exists in distributed binaries.
  4. Long-term Persistence: Maintaining access across multiple releases and updates.

Impact

The potential impact of such a compromise could be severe, including:

  • Mass surveillance of users
  • Theft of sensitive data
  • Creation of large-scale botnets
  • Targeted attacks on high-value users

Generic Issue Applicable to Many Projects

This forum post discusses Qubes, but the issue is not specific to Qubes. It applies to all Linux distributions, all operating systems, and even most complex applications.

80/20 Principle Application

I am describing this situation using the 80/20 principle. The description should be correct for at least 80% of users. It might differ for a small minority of highly technical people.

Questions and Answers

Why Is This About Core Developers?

Because these are the ones creating binaries that thousands of users will use as-is. In theory, if the core developers were malicious or compromised, they could spread backdoored binaries.

Let’s Suppose the Core Developers Are Not Malicious…

Sure, let’s assume the core developers have good morals and do not intend to backdoor the software. However, core developers could be compromised. Being compromised is different from being malicious by bad character.

How Could the Core Developers Get Compromised?

Some examples:

  • Physical Attacks: An attacker might gain physical access to their computer while they are away (shopping, on holiday, sleeping).
  • Threat or Blackmail-Based Compromise.
  • Software Attacks: An advanced adversary might find or purchase zero-day exploits and use them against the core developers.
  • Hardware Backdoors.

How Likely Is It for Core Developers to Get Compromised?

Unknown, and not important for the sake of this argument.

Why Would an Attacker Want to Compromise Core Developers?

There is significant monetary value in compromising an entire operating system. This is more valuable than compromising individuals, which happens frequently (primarily on the Windows operating system).

Is There Any Specific Reason to Distrust the Core Developers?

No. In the context of this argument, trusting the core developers versus not trusting them does not make a difference.

But Qubes Is Open Source, So It Doesn’t Matter If Core Developers Get Compromised?

Unfortunately, this is wrong for a few reasons:

  1. There hasn’t been a complete source code audit yet. Also, “audit” can mean many things. It is not a one-time, definitive check. Every audit has a scope, is performed by fallible humans, and is very difficult, making it easy to overlook things.
  2. Even if an audit has been completed, there is a constant stream of source code changes. These would need to be continuously audited as well.
  3. Most people use binaries rather than source code. In theory, reproducible builds and rebuilders would ensure that binaries match the source code used to create them. However, this has been a development goal for many years and could take multiple more years or even decades to fully implement due to the technical complexity and the small number of contributors. Until then, this argument remains applicable.

No progress in Make the whole qubes-builder deterministic · Issue #816 · QubesOS/qubes-issues · GitHub since 2020.

Reproducible Builds?

Reproducible builds are a set of software development practices that create an independently-verifiable path from source code to binary code, ensuring that a given source always results in the same binary. This approach addresses many of the trust issues raised earlier by allowing independent verification of binaries without requiring users to build from source themselves. The full implementation across all open source projects remains an ongoing challenge.

Hidden Source Code

There is no easy way to verify that a specific source code was really used to create a provided binary until reproducible builds are implemented and people actually check (rebuilders). Until then, core developers could upload one version of source code to the repository but use different, backdoored source code to create the actual binaries.

But I trust core developers won’t do that? Ok, it’s easy to grant that core developers are not malicious. However, as mentioned above, core developers might be compromised. Compromised core developers might not even notice that hidden, backdoored source code is being injected without their knowledge during the build process of binaries.

How to Be Safe from Hidden Source Code-Based Backdoors?

Build images from source code and install upgrades from source code only as well.

What “building from source code” means in the context of building Linux distributions from source code is not well defined.

Who Always Builds from Source Code?

I am unaware of anyone who has publicly confirmed to always build images and upgraded packages from source code.

How Difficult Is It to Always Build from Source Code?

Extremely difficult. Building images requires Qubes builder. Users are failing to create images. The reported issues remain open and unfixed for months. Unfortunately, fixing such issues seems not a priority for the Qubes core developers.

As currently implemented, building Qubes images using Qubes builder does not help much either.

How Much Is Accomplished by Building Qubes Images Using Qubes Builder?

It’s nice to do that, but not much is accomplished. Even if using Qubes builder, you’ll most likely still be using binaries that you have not built yourself. Evidence?

Just search Qubes source code for deb.qubes-os.org. For example, see: QubesOS/qubes-builder-debian/blob/main/template_debian/distribution.sh

deb [arch=amd64] https://deb.qubes-os.org/r${USE_QUBES_REPO_VERSION}/vm ${DIST_CODENAME} main

What does that mean? That Qubes binary repository is being used during the Qubes image build process. Therefore, not touching any binaries created by Qubes is already extremely difficult.

Why Not Use Any Binaries from Qubes?

Good question. To avoid backdoors until reproducible builds protect from compromised core developers. It would be nice if that was possible, but…

How to Avoid Using Any Binaries from Debian and Fedora?

This would be even harder to accomplish. And why trust Debian, Fedora but not Qubes? For attack surface reduction, it would be nice to avoid any binaries created by Qubes, but it would still be very incomplete.

How Likely Is It to See a “Source Code Only, Strictly No Binaries” Build Process?

Highly unlikely, but I would be more than happy to be proven wrong.

How to Upgrade Packages from Source Code?

I don’t think this is really being discussed, documented, or supported.

Why Isn’t Always Using the Source Code for Images and Upgrades and Avoiding Binaries Better Supported?

Possible reasons:

  • Longer build times.
  • Low demand. Users want stuff to work out of the box, without issues, and with simplicity.
  • Not a project priority.
  • Highly difficult to develop Linux build scripts with numerous different use cases.
  • Developers might think efforts are better spent towards reproducible builds than on a minority of technical users building everything from source code.

But Open Source?

If >=80% of users lack the technical capabilities to make actual use of the source code and avoid all binaries, then this argument is somewhat moot.

Are highly complex, expensive, years long backdoor attacks against Open Source happening?

Yes, see the recent xz backdoor.

Should I Use Something Else?

No. This is not my argument. Maybe a source-based distribution, but the ones I looked at have other issues. (Security-Focused Operating System Comparison as Base for Whonix)

Open Source is certainly better to avoid backdoors. It is still much harder to spot backdoors in closed source software than in Open Source software. No need for fatalism, no need to go back to Windows.

The Right Questions?

  • How to build and use Qubes from source code while never using Qubes repository / any Qubes binaries?
  • How to build and use Debian from source code while never using Debian repository / any Debian binaries?

How to improve this situation?

  • Contribute to reproducible builds.
  • Contribute to build from source code without touching binaries / binary repository.
9 Likes
120

Thanks for the great explanation!

Do you know of an OS that actually utilizes regular audits or something similar?
If yes, how do they accomplish this?

121

boreas via Qubes OS Forum:

Do you know of an OS that actually utilizes regular audits or something similar?

No.

1 Like
122

OpenBSD does regular audits - read more here
There are others, like AstraLinux, KasperskyOS, and some government
systems, but they are not free.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like