For the last few days, I have been following this thread about Qubes possibly being a honeypot. I think that this is a very valuable discussion, but so far I find it rather disturbing. There are many arguments for and against this proposition, but they are rather unstructured and so have no chance to come to a real conclusion.
What is needed, in my opinion, is a systematic approach to this question, and that needs to build a threat model, analyzing which threats are relevant and which are not. I will try to collect these arguments and structure them in the following paragraphs. Please excuse if it is a rather lengthy text, but Qubes is a complex system, and so the threat model is complex, too.
The first question is: Can / should we trust the ISO used to build Qubes?
This file is accompanied by a digest and a PGP signature, based lastly on the Qubes master signing key whom you have to trust as a security anchor. The fingerprint of this key is rather widely available, so there is some hope that you will get the real thing and not a fake one. Downloading the ISO file and checking it against its digest will assure you that you get the correct and unmodified file provided by the developers.
But is this really the system built from the correct sources?
Contrary to closed source software like windows, you have the possibility to dowload the sources, check them against their signature in github and build the ISO file yourself. This process is well documented and, according to cries for help in the forum, is used by a lot of Qubes users. So there is the possibility to have a Qubes installation media verifiably consistent with the sources.
But do you trust the developers to provide sources without backdoors?
This is rather a key question. As has been correctly pointed out in this thread, there exists the possibility that one or more developers might be forced or bribed to install a backdoor somewhere in the sources. If this were well hidden, most users will not be able to detect it. On the other hand, if not all developers were subverted - which is highly improbable due to their worldwide distribution - some of them will surely detect code that should not be there and start asking questions.
Here the canaries, which are published every three months or so, come into play. In these canaries, the Qubes team assures that the system is clean and not compromised and that no attempt has been made to force the introduction of unwanted code. While possibly one of the signers of these canaries might have compromised the system and be forced to state the opposite in the canary, it is highly improbable that all signers could be forced to sign such an untrue statement, just because they work in different countries and under different legislation. And since they are developers and understand the system, they would detect such a modification and reject signing a false statement - and not all of them can be forced to sign it anyway.
There is one more argument: Since Qubes is an Open Source project, the group of developers might, at any time, be joined by new developers, as has occurred several times in the past. Hiding a backdoor from these new members of the team will be impossible so thus even if a backdoor was installed at some time, it has no chance to stay undetected.
Could a third-party review detect backdoors in the source?
@anon11917472 rightly states that the openness of Open Source is of no additional value if no one inspects these sources. To get trust in these sources, audits have to be performed, analyzing the sources in depth and checking for potential security flaws. At least one such audit has been performed by the Freedom of the Press Foundation, for its SecureDrop workstation. The audit has shown some minor bugs, but no backdoors. It is, however, somewhat difficult to estimate the value of this audit, as its depth is, to my knowledge, not sufficiently documented. According to ISO/IEC 15408, an audit that would reveal backdoors in the sources should be done at level EAL5 or higher, but even at lower levels, backdoors might be found.
It would greatly enhance the confidence in the sources of Qubes if such an audit would be performed by one of the official certification bodies, and I think that it is a serious deficiency that, to my knowledge, this has not been done already. (For this, I have already contacted the BSI, the German government security agency, but they seem to have no one in charge of operating system security, and there is nobody available to finance such an audit!)
What implications of Qubes system Architecture are there?
Qubes heavily relies on compartmentalization and isolation of system components. This is somewhat ignored by the critique of @anon11917472, when they remark that an unhardened Firefox is used, which might pose some risk. I do that myself: For surfing, I just use the standard untrusted Fedora qube with the Firefox provided there. I have even added some extensions which may increase or decrease its security - I don’t know and I don’t care! This qube has no valuable data, just some files that were downloaded, could be downloaded again if needed, and will be thrown away after inspection. So, even if this qube were somehow compromised permanently, e.g. by inserting something bad into the Firefox profile, it does not matter at all. If necessary, I could throw the whole qube away and recreate it within minutes.
This situation would be different if an attacker could break out of this qube and attack other parts of Qubes, possibly even dom0. But this would require the attacker to find a loophole in Xen which could be used from one of the VMs. Such a loophole would not be a backdoor in Qubes itself, but an upstream fault in its supply chain. In order to get control over Xen, an attacker would have to cross the hardware ring protection provided by the processor and get from the maximum ring 1 allowed for VMs to ring 0 reserved for Xen, and this would be such a serious fault that it cannot stay undetected for a longer time. Such faults have existed for the whole lifetime of Qubes and they are a consequence of using Xen as its technical basis. But, if and when such a fault has been detected, it will normally be corrected within a few days and so has only a rather limited impact.
With this one exception, my permanent data are protected, as they are lying in a different qube, having no network access and no software like Firefox installed, and, just for enhanced security, being based on a different operating system (Debian instead of Fedora). All this except the last point holds true for dom0, which therefore cannot be compromised unless there is a serious flaw (or backdoor?) in Xen. But Xen, too, is Open Source and thus could (and should!) be subject to the same audits as Qubes.
For access to sensible websites, I use the Tor browser in a Whonix AppVM or, for higher-risk locations, from a dispVM based on Whonix. I assume that the Tor browser in its basic configuration, is more secure than the unhardened Firefox, and that any compromise of it, which would not only affect Qubes, but also Whonix and Tails, would be and has been quickly corrected.
What about the costs of an attack?
The arguments above, mainly the multi-party structure of the development team and the effect of compartmentalization, raise the needed effort and therefore the costs of a security compromise of Qubes considerably. So attackers working on the principle of getting most bang for their buck would surely give a wide berth to Qubes and instead attack systems like Windows or MacOS, where they have more targets, and success can be achieved without much effort. So, probably, you and I will have nothing to fear from such attackers, because we are simply not worth the effort.
But what about some possible high-profile users of Qubes? Such a user might be attacked with nearly limitless effort, for instance, if some three-letter agency decides to attack them. But such a user would - if they are serious - not use Qubes unprotected and without additional security measures. There would probably be firewalls, intrusion detection systems, and a decent network structure, and such a user could and probably would do source audits so that any backdoors in Qubes would be detected prior to its deployment. So even there is no need to use Qubes as a honeypot, as it would not work at all.
One should not overlook the fact that security is not only technical security but there are other ways to reach the goal of a security breach. Instead of spending a million dollars on subverting an IT system, the same result might be reached by paying a suitable user of this system a thousand dollars for the data to obtain.
Conclusion
Qubes is a highly but not absolutely secure system. Trying to use it, via some backdoors, as a honeypot would be extremely difficult and, from an economic view, might not make sense. Following this reason, Qubes is secure, and that is just what is claimed, to be a reasonably secure operating system. So, at least, I am glad to have it!