Qubes OS could be honeypot?

General Discussion
88

The hardening of Firefox or any other application inside a VM is nothing to do with the Qubes OS main focus of compartmentalization.

4 Likes
89

I have already said it appears I was just dumb for making assumptions. I should have known better and typically I do.

Also most of this is just people misunderstanding what I meant to say so I am probably a poor communicator as well.

Also none of this really has anything to do with the original point I was bringing up to the person that made the original post.

The assumption I had made was that the default personal VM was somehow more secure than a typical Firefox install on Windows 10 and it seems as though I am being told it is not. This is not a big deal as I to my knowledge have never been hacked using vanilla Firefox.

Another assumption that I had made was that since there was a Firefox shortcut on my personal and work browser it was okay to use them and it seems like now I am being told that it is not unless I want to open myself up to Firefox related hacks potentially gaining persistence on my personal/work VM.

This is fine and now that I understand it I can proceed accordingly and adapt my workflow.

Also I am not arguing anything in any of this, I was just responding as sort of a devils advocate to what logically appear to be flawed arguments. Some of those arguments seem a lot more logical now that I understand how Qubes works better.

Most of the recent posts are arguing with a person that doesnt even exist because my mind was changed on many of the points people are arguing against days ago.
It is pretty obvious who comes in and reads the first post and comments without reading the rest. This is understandable because much of what I have said looks a lot like something you would see written in sharpy by a schizophrenic homeless person on an old pizza box.

The main thing I learned is that I need to harden my personalVM Firefox myself if I want to be able to use Firefox to copy and past into text documents without a huge hassle.

90

Indeed, but that wasn’t the scenario under discussion. I was addressing only the point about being a high-profile target.

91

Thank you. The entire point of all this is to compartmentalize so you do not have to trust any one particular thing. Qubes-OS is trustworthy in the sense that one is protected because it is compartmentalized to protect the system from one compromised component. Its as fail-safe as any software can be.

4 Likes
92

I know that the hashing power of the bitcoin network can’t be redirected to cracking passwords, not even by the NSA or other 3-letter agencies, because the ASIC chips that all profitable miners use are physically made to solve /only/ bitcoin’s SHA256 hashing algorithm. An application-specific integrated circuit (abbreviated as ASIC) isn’t a general purpose computer chip that can be programmed for general computing tasks; rather ASICs can only calculate the bitcoin algorithm. What is that algorithm? They’re searching for a very specific hard-to-find number (a “nonce”) with a certain number of zeros in front of it, that can only be found by rapidly trying number after number after number. Whoever finds it first gains the right to issue a block of transactions from the mempool (memory pool of unconfirmed transactions), and the network then begins looking for the next block’s nonce.

Since 2014 its not been possible to profitably mine bitcoin using GPUs or regular general-purpose CPUs; only ASICs are profitable (unless you’re very small scale with free electricity). But the vast majority of miners run ASICs and those chips are only good at running bitcoin, not other computing tasks. (If you want to read more on ASICs, see here: ASIC - Bitcoin Wiki).

You’re correct to generally distrust general-purpose CPUs, especially where the Intel Management Engine isn’t in your control or disabled/removed. But this isn’t applicable to the bitcoin mining network—its a separate problem.

93

Reassuring :grin:

Agree :100:

Acknowledged

My guess: fear.

Truth that bears repeating.

As much as I enjoy philosophical discussions I think this is off-topic. @anon11917472 please correct me if I am missing something.

Are you still talking about keyboards or have you circled back to confidence that Qubes could be a honeypot?

:laughing:

But the philosophical question is, of course, how do we know they ever existed at all? (Bear with me unfortunate readers, I’m slowly getting to a point) Didn’t you take knightmare/xSCAMMMER0’s course? I’m confused so please correct me if I am wrong.

Does the current @anon11917472 if he/she/it exists at all still believe this?

Me too. (but it can be a good diversion from dealing with serious real world problems imho… just my $0.02)

  • Best
94

Nah, the FBI is too busy monitoring people posting mildly edgy takes on twitter

1 Like
95
Pointless Post

Assuming the FBI reference is a joke :smiling_face:

Twits are undoubtedly :jokers: nowadays. :laughing:

The siloed nitwits at the FBI seem WAY out of their league (even with “Fusion Centers”) if they think they’re making inroads into the qubes community. :rofl:

If I’m wrong please tell me more. I’m really really interested. No personal offense @jpbaiocchi I presume we are :laughing: together, but if I am mistaken I’m not just @confused but very curious.

  • Best
96

Not really.

Interesting assumption. Who do you think it is for?

Hahaha. That was a joke, right?

Obviously

Always nice to meet an 31337. Pleasure to meet you! Any tips?

So that’s what I was smelling.Thanks for clarifying.

I doubt the computer scientist part is the major issue, but I have been wrong many many times before.

Please help me understand. All I smell is BS.

Not yet.

Are we in conspiracy land or have I missed the reference (hidden link somewhere)?

Nope. Do you?

Were the Snowden “dumps” 20 years ago already? Did I miss a good or bad decade?

DARPA made us all their B/tches long before that (based on your logic). When did you first get on the ARPAnet…sorry I mean the Internet.

No prob. As long as this remains in General Discussion I like reading compulsive Aspie theories. You might be surprised how many ARPAnet creators fit in that category. But since I’m new here, I’ll shut up and read the rest of this “honeypot” discussion before I say more.

Good luck to you also!

97

Well……that escalated quickly…… :grimacing:

3 Likes
98

Also TommyTran if you are waiting for Microsoft to admit to backdooring Windows you might be waiting for a while. I would suggest you research the term “plausible deniability”.

You shouldn’t make claims that have not been proven.

Microsoft also holds the authentication key for Windows and can put anything they want in Windows at any time.

You just made this up. Where is the proof that Windows currently currently have something that allows arbitrary code execution from Microsoft’s server and that it is an actual backdoor?

If you are talking about a malicious OS update, that is applicable to any operating system, be it Windows, macOS, ChromeOS, the BSDs, generic Linux distributions, or Qubes.

What better backdoor can you want more than being the one pushing closed source updates at will. I mean think bud. No backdoor LOLZ.

Conspiracy talk. Open source developers can trivially push malicious updates too if they wanted to. You should stop fear mongering about proprietary software.

But you can read the Snowden leaks to find more examples or actual backdoors, for example handing the NSA preEncryption access to all of Outlook.com

Outlook doesn’t have per-user encryption key to begin with. Of course they have access to your emails after-the-fact. This is applicable to any generic email provider, be it big ones like Gmail, Outlook, or smaller providers.

Even encrypted email providers like ProtonMail or Tutanota with per-user encryption key, users are only protected from a malicious actor from reading the emails after-the-fact. Their servers can still see the content of most emails as they come in unencrypted.

This is to be expected of any email provider. I suggest you read into how the protocol actually works instead of just reading headlines and make outlandish backdoor claims. You really need to stop making things up.

99

So, here’s the entire source code for the entire Qubes Project:

Also, here’s the entire source code for a “Qubes Builder” that the awesome devs have made:

If you don’t trust the pre-made ISOs, audit the source code, and bake your own :slight_smile:

3 Likes
100
Sorry for the BS post

My bad. Saddened to see I made you :grimacing:

(I’d like to blame it on the whiskey, but I was the one who clicked Reply).

Thanks for bringing things back on track @alzer89!

1 Like
101

There are hundreds of millions of code, in QubesOS, Xen, and several default templates and apps. It’s a small set of developers. If an insider developer modifies small part of the code creating an escape vulnerability, who is going to detect this needle in haystack? It will likely never be known.

Also, auditing a 50 MB app is costly and still limited , let alone a 6 GB codebase, which is near impossible.

So yes, you need to trust the developers. This is not unique to QubesOs, rather, it’s more important in this context since Qubes users usually believe they have something to hide, sometimes from powerful states. You want escape exploits in the hypervisor, it pays off.

1 Like
102

On the other hand the sheer compartmentalization makes it more difficult for certain sorts of exfiltration to occur. LibreOffice, say, could be spyware, but if it only runs on a qube with no network access, all you have to do is verify the latter, not the entire LibreOffice codebase.

2 Likes
103

You are thinking about it the wrong way. The TCB is only a very small percentage of all that code.

From the intro:

In building Qubes, our working assumption is that all software contains bugs. Not only that, but in their stampeding rush to meet deadlines, the world’s stressed-out software developers are pumping out new code at a staggering rate — far faster than the comparatively smaller population of security experts could ever hope to analyze it for vulnerabilities, much less fix everything. Rather than pretend that we can prevent these inevitable vulnerabilities from being exploited, we’ve designed Qubes under the assumption that they will be exploited. It’s only a matter of time until the next zero-day attack.

In other words: Yes, there are hundreds of millions of lines of code in the entire stack. We can’t possibly check all that, so let’s instead make it so that we don’t have to. How? By compartmentalizing everything, and making the layer responsible for the compartmentalization as small as possible. Then we just have to make sure that part is secure.

3 Likes
104

This is correct, but reductive. I was referring to a vulnerability that would compromise the security guarantees of the QubesOS, such as an escape vulnerability. This could be in the Xen (added or already there), dom0, sys-firewall, sys-net, or myriad of ways that the virtual machines interact with those. For Tor and Whonix, this could be a bug within VM.

1 Like
105

A bug in sys-net, for example, could never compromise the security guarantees of Qubes OS, because the security model of Qubes OS explicitly assumes that sys-net is already compromised.

1 Like
106

Sys-firewall could.

Couldn’t sys-net alter or hijack DNS/IP and serve the user with malicious JS content that would compromise other browsers in other VMs, contact CC, and basically MITM traffic. It’s like your ISP or part of your router

107

Yes, and it’s on you to use SSL, or some other way of making a secure connection.

2 Likes