What about a more casual qubes?

General Discussion
21

When comparing two similar closed source software A and B all you can do in the end is to weight the amount of trust you can put in the people/company behind each software that they implemented the software features properly.

You compare their feature set and at least the general architecture of how they implement things. People also do security research into the proprietary solutions as well.

Now with open source software B we can at least have something technical to assess.

It is easier to study, but that is about it.

2 Likes
22

Yeah, I do think it should be cut off to form a different thread starting from this comment: What about a more casual qubes? - #7 by balko

I should stress here that I am not saying that either open source or closed source is better. All I am saying is that you really, really should evaluate the product based on technical merits and not fear monger.

I do get really irritated that when I try to post something nice there’s always someone derailing it with “hurr hurr proprietary bad”.

2 Likes
23

I do not want to be a topic starter due to reply to this toxic person. And there is no room for new discussions from me to them (and thus being a topic starter), because I did not read @TommyTran732 posts with a lot of text starting from their clown emoji and other offensive stuff.

I propose this off-topic should be left here as is and stopped.

2 Likes
24

It’s down to trust again.
Tomorrow some unknown company will release some encryption software and describe its architecture out of black boxes and claim some magical features.
And you won’t be able to verify their claims in any way except for reverse engineering.

It’s much easier.
And the issues such as this one are very hard to come by in some more or less known and widespread open source projects:

6 Likes
25

Tomorrow some unknown company will release some encryption software and describe its architecture out of black boxes and claim some magical features.

True. That happens a lot. I have seen it happening with some open source projects too, though.

And you won’t be able to verify their claims in any way except for reverse engineering.

Also true.

It’s much easier.

True. I agree that it is much easier to notice the nonsense in the open source stuff as well.

However, it really should be stressed here that we are originally talking about Filevault 2, which is really not some magical blackbox where some company just claim to implement certain things.

There are actual people (who know what they are talking about with regards to encryption) doing research into Filevault 2, and from their papers it seems sane.

2 Likes
26

Read the topic. You mentioned Filevault for the first time only after throwing offensive clown emoji. While I was replying to your statements about you comparing security of “MacOS + Parallels + Windows VMs” with Qubes OS. For me it’s obvious, that adding backdoor or basic mistake that would destroy security (like using xor instead of proper encryption or using time-based random generation like Kaspersky used) in your proprietary combination is WAY more possible, because it is harder to find such problems.

I do not want to convince you otherwise, nor I want to speak about your Filevault that I never used, no care about. Just be polite about other people opinions, especially considering there were so many cases when proprietary solutions, including encryption software, were in fact defective by designed and there was no way to find it out for a long time (or never) due to its proprietary nature, as you were told by other forum members.

Nonetheless, I am sorry for causing your anger in this topic.

2 Likes
27

With Filevault specifically the reverse engineered version from 10 years ago could be proper. But someone needs to repeat the reverse engineering periodically to check that there were no design changes introduced that could be an issue.
Maybe there are people that do this but they just don’t report about it since there is nothing interesting to report but their number would be really small even for such a widespread software compared to the number of people that’d check the open source project because it’s much easier to check.

5 Likes
28

Read the topic. You mentioned Filevault for the first time only after throwing offensive clown emoji.

No, you brought it up. You brought up encryption.

While I was replying to your statements about you comparing security of “MacOS + Parallels + Windows VMs ” with Qubes OS .

macOS encryption is Filevault 2. What do you think macOS uses?

For me it’s obvious, that adding backdoor or basic mistake that would destroy security (like using xor instead of proper encryption or using time-based random generation like Kaspersky used) in your proprietary combination is WAY more possible, because it is harder to find such problems

But there is no proof such thing exists in Filevault 2, and Filevault 2 is not some unknown encryption software a random company magically came up with. I linked to some actual research papers above.

Also, why are you implying that there is a backdoor in Filevault 2 to begin with? Where is the proof?

Just be polite about other people opinions, especially considering there were so many cases when proprietary solutions, including encryption software, were in fact defective by designed and there was no way to find it out for a long time (or never) due to its proprietary nature, as you were told by other forum members.

See? You just made stuff up again. You made up an “expert” who says it is about as trustworthy as XOR. You are just fear mongering.

2 Likes
29

No, I was not talking about disk encryption in particular. It’s your misinterpretation. I do not even know the name of proprietary closed-source software that apple uses for disk encryption.

  • Firstly, encryption is used everywhere, not only for disk encryption: messengers, browser, email client, backups, everywhere.
  • Secondly, I was talking about encryption as example of proprietary (one again, more importantly: closed-source) solutions. Like, I personnaly know the case when “encryption” app for Android was actually xor-ing first N bytes of the file, insane right? And when the app is closed-source, compiled, obfuscated and the output is not that obvious, it’s insanely hard to find it out.

A bit more about encryption, I stressed the closed-source term several times for a reason. There are solutions that ARE proprietary, but more reliable, because they decided to share code EXACTLY for the reason I was talking about: to gain trust. Like one of the most famous truecrypt competitors at the time (forgot the name, you can search).

By the way, truecrypt and veracrypt also can be considered to be proprietary, but quite trustworthy due to their history and being at least source-available software (not closed-source).

And yes, I personally do not trust bitlocker nor your apple vaults. Of course, there is a chance it’s back-door or badly implemented somewhere, and not you, nor I can prove it or prove otherwise yet, because it’s closed-source piece of blob.

I would not recommend friends trusting it due to this reason if they have a choice.
And yes, Filevault 2 is garbage in my eyes a priori, needless to say I would have to use garbage OS to use it. It’s my opinion, sorry if you do not like it.

About experts that assume that closed-source software should not be trusted more than xor: sorry, I won’t name names, if that what you are so worried about, nor have I never promised to do that.

3 Likes
30

Do you want to give some more context on Filevault 2 specifically? If we’re talking about something that’s unchanging (seems unlikely) and has been completely reverse-engineered then that approaches some equivalence to having the source code available to read and build.

Until someone talks about concrete vulnerabilities in Filevault, which wasn’t being proposed, there’s no way for anyone to engage meaningfully with your questions about proof.

Trusting expertise on how a black box behaves, which is what you’re doing if you’re referencing papers without verifying their methods and reproducing their results, basically adds another black box, and another obstacle to persuading other people. Again, you have the option not to with open source.

Found a better reference regarding trust, that can be applied to this discussion.

one of our primary goals is to free users from being forced to entrust their security to unknown third parties. Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).

I’m among the people using proprietary to mean closed-source. Apologies.

4 Likes
31

I do not even know the name of proprietary closed-source software that apple uses for disk encryption.

Well now you know. You really shouldn’t be making claims against it if you don’t even have a vague idea of what it is or how it works conceptually.

  • Firstly, encryption is used everywhere, not only for disk encryption: messengers, browser, email client, backups, everywhere.

Messengers, browsers, and email clients use the same thing they use everywhere on Windows, macOS, Linux, or any other platform. There is no practical difference, maybe apart from which CAs are trusted.

Backups are Filevault 2 again (albeit not backed by the the Secure Element).

I am not sure why you even bring this up because it doesn’t make any sense. If you are worried about the OS, the relevant thing here is the OS disk encryption since they are widely different. Oh, and on top that, my original post only mention better disk encryption handling than LUKS, so when you reply to it with “hurrr hurrr untrustable encryption” how am I supposed to read it?

And when the app is closed-source, compiled, obfuscated and the output is not that obvious, it’s insanely hard to find it out.

You can use the same logic against open source stuff too. The distributed executable can be different from the open source stuff. Are you gonna read everything, check every code changes, then compile everything yourself?

By the way, truecrypt and veracrypt also can be considered to be proprietary, but quite trustworthy due to their history and being at least source-available software (not closed-source).

Not-so-trustworthy. Actual technical reasons (albeit unrelated to the cryptography since I do not know cryptography):

  • Veracrypt doesn’t even support UEFI secure boot by default. You have to go out of your way to sign it every time if you wanna keep Secure Boot.
  • No TPM support. This makes it impossible to have any kind of tamper detection and rate limiting. Meanwhile, with Bitlocker, you can use TPM for rate limiting and bind to PCR 0,1,2,3,3,4,6,7,11 to have some tamper protection. Oh, and unlike systemd-cryptenroll, Bitlocker doesn’t blindly trust the TPM either, so even if the TPM’s internal state is compromised your encryption key is still protected: 2304.14717 (arxiv.org). macbooks have rate limiting with the Secure Element too: If you try to bruteforce it it will just lock you out.
  • This is a third party app with admin privileges on Windows, so it is extra attack surface. On macOS, it requires a whole system extension, so you have to reduce the boot security policy from Full Security to Medium Security.
  • All of this, and for what? When you use an OS, you implicitly trust the OS vendor. The only time when you shouldn’t be using their encryption method is if there is something seriously wrong with their implementation, or when there is some significant security improvement to be had. All of the stuff I listed above are just weakening security while providing no real apparent benefit.

And yes, I personally do not trust bitlocker nor your apple vaults.

And yes, Filevault 2 is garbage in my eyes a priori , needless to say I would have to use garbage OS to use it. It’s my opinion, sorry if you do not like it.

You just say stuff for the sake of saying it, without any sane technical reasoning. This is why we can’t have a productive conversation: You keep airing your opinions that are not backed by anything. It doesn’t lead to anything fruitful. It is just to spread fear, uncertainty, and doubt. Please at least provide any real technical reasoning beyond just “hurr hurr closed source untrustable”, or you can just say nothing and this argument would have never needed to happen.

About experts that assume that closed-source software should not be trusted more than xor: sorry, I won’t name names, if that what you are so worried about, nor have I never promised to do that.

Yeah, because you made them up.

1 Like
32

I am not sure what you are referring to.

Until someone talks about concrete vulnerabilities in Filevault, which wasn’t being proposed, there’s no way for anyone to engage meaningfully with your questions about proof.

A certain someone brings up magical backdoor and says its about as trustworthy as encryption using XOR.

Trusting expertise on how a black box behaves, which is what you’re doing if you’re referencing papers without verifying their methods and reproducing their results, basically adds another black box, and another obstacle to persuading other people.

Not how it works in reality. Did you read LUKS’s source code yourself? Did you verify that the LUKS binary and distributed by Fedora/Qubes match the source? Did you verify that Anaconda (Fedora/Qubes’s installer) sets up LUKS in the most optimal way? (hint: it doesn’t - it is missing dm-integrity). It is as much of a blackbox as what you just described if you do not do the work.

Again, you have the option not to with open source.

Just waving at people saying “this is open source therefore it must be trustworthy” doesn’t help anyone. You need to discuss the actual security properties. I can point to some actual weakness with how LUKS is generally done on Linux right now (and no, this doesn’t require me to read the source code) compared to other solutions:

  • Encryption key is stored in memory → This is well known. Without memory encryption, an physical attacker can extract the encryption key from your RAM. There is also a chance that a malicious process on the system can extract the key through some exploits. Macbooks do this better by having the Secure Enclave handle encryption transparently and the encryption never touches the RAM. On commodity hardware, you can use Intel Key Locker so that the actual encryption key only needs to be stored in memory in very early boot, and can actually purge it from Memory in normal operation. ChromeOS does this, but regular Linux distros do not.
  • TPM handling with systemd-cryptenroll. This is not specifically a LUKS problem, but it is how Linux distros setup TPM unlocking with LUKS and tamper protection. The actual key protector is sealed as is into the TPM as is, so if the internal state of the TPM is compromised your key protector will get leaked. Bitlocker doesn’t have this problem. This is shown via research: https://arxiv.org/pdf/2304.14717
2 Likes
33

But it is subceptible to a hardware sniffing bypass on certain Lenevo laptops.

https://forum.qubes-os.org/t/breaking-bitlocker/24234 (All around Qubes)

2 Likes
34

Nobody here was saying that. You probably missed the point or make a logical mistake.
What was really told, is that for many people (me included) being at least source-available product is a BARE minimum for calling it to be trustworthy. Minimum, not enough.

The combination you use MacOS+Parallels (why do you trust this companies?) does not meet this basic, bare minimum criterion. And saying that it is more secure than Qubes OS or is similar does not look convincing to me.

In my opinion, that it does not meet the bare minimum requirements to be trusted in the first place, because it’s a piece of proprietary closed-source software with gods knows what inside. That’s why I asked why you trust them in the first place. I hope my point is clear for you now.

About your multiple questions “how to check if the sources correspond the binary”. It’s in fact a well-known security topic, at least among security specialists. You should read about reproducible builds and why it is important and preferable to have if possible. This topic what raised for Qubes OS many times (partly implemented, not a top priority, though).

Finally, even if you have no reproducible builds, and want to check if the sources fit the binary, it’s still million times easier compared to finding intentionally added tricky backdoor in a huge compiled binary blob. It looks obvious, not sure why you argue with such fact.

3 Likes
35

This left out a lot of the nuances.

  • Yes, it has the problem where an attacker can sniff on the communication between the TPM and the CPU.
  • This does not affect fTPM at all, because the fTPM isn’t a separate chip.
  • This attack can’t magically work against Bitlocker with a TPM + PIN setup, which everyone should use when they rely on Bitlocker. The attacker cannot sniff anything without knowing the actual PIN (the TPM will not and cannot just release the unencrypted version of the key protector). Even if he can attack the TPM and get access to its internal state, he can’t do anything because it is not the unencrypted key protector inside of the TPM. However, in the case of systemd-cryptenroll, even if you set up the PIN, you are entirely trusting the TPM, because systemd-cryptenroll puts the actual unencrypted key protector inside of the TPM.
2 Likes
36

What was really told, is that for many people (me included) being at least source-available product is a BARE minimum for calling it to be trustworthy . Minimum, not enough.

This is not how the real world works.

The combination you use MacOS+Parallels (why do you trust this companies?) does not meet this basic, bare minimum criterion. And saying that it is more secure than Qubes OS or is similar does not look convincing to me.

Criteria that you made up.

And I clearly did not say it is more secure than Qubes - I said it has pros and cons. One of the pros is the encryption handling/tamper protection for reasons I have stated over and over.

You should read about reproducible builds and why it is important and preferable to have if possible. This topic what raised for Qubes OS many times (partly implemented, not a top priority, though).

Well aware of what it is. I have news flash for you: your actual Qubes OS build is not reproducible. Neither is Fedora which your dom0 and various templates are based on. And the “reproducible” Debian has a bunch of downstream god-knows-what patches that cause more problems than good.

Finally, even if you have no reproducible builds, and want to check if the sources fit the binary, it’s still million times easier compared to finding intentionally added tricky backdoor in a huge compiled binary blob . It looks obvious, not sure why you argue with such fact.

How? Using what magical method? If I were to attempt this backdoor in a compiled kernel and not the source, will you really find it because it supposedly looks so obvious? How long will it actually take you until you realize you have been pwned?

The Linux Backdoor Attempt of 2003 - Freedom to Tinker (freedom-to-tinker.com)

2 Likes
37

That is how it works for me. I don’t use proprietary OS and proprietary Parallels software because I have a choice. Works fine.

No, it’s criterion that I chose for myself. MacOS+Parallels does not meet this bare minimum criterion of being trustworthy. That I and many other people stick to.

Why do you have to twist other people’s words in almost every post? Was I saying that it would be “so obvious” or super easy? It is easy compared to doing it for proprietary compiled blobs that you have no sources of.

And there is no magic method. You would probably had to compile the software with the same compiler and similar or the same level of optimization. Than you make a binary diff, disasm and analyze only the differences. It’s hard and time consuming.

But this difficulty is no match for disasm of the huge proprietary pieces of closed-source blobs that you use, which is MUCH more difficult if at all doable. Don’t you agree?

Another approach is to compile the kernel from sources and use it if you do not trust one from maintainer. It’s not that difficult. You can even build GNU/Linux from scratch (or Qubes OS). And all that is completely not possible when you use a stack/pile of proprietary solutions (like you do), when user have to almost blindly trust apple, parallels and other “reliable” guys.

2 Likes
38

Actually can you elaborate on this? I heard that ChromeOS is quite good with sandboxing so I am actually considering giving it a try.

2 Likes
39

And there is no magic method. You would probably had to compile the software with the same compiler and similar or the same level of optimization. Than you make a binary diff, disasm and analyze only the differences. It’s hard and time consuming.

But this difficulty is no match for disasm of the huge proprietary pieces of closed-source blobs that you use, which is MUCH more difficult if at all doable. Don’t you agree?

You have to do the same reverse engineering work you have to do with close-sourced/proprietary software. There is little to no difference.

And let’s be realistic here: you are not going to read the code anyways, so the entire argument is moot. Not even the maintainers of the package actually verify what they are building beyond a quick cursory look (like with the xz backdoor). Auditing 1 or a few pieces of software can be someone’s full time job. At the end of the day, you need to trust someone else to do 99% of the work. From the perspective of a user a binary compiled from the source code they didn’t read, a binary compiled by someone else, or a closed-source binary are about as opague as each other.

No, it’s criterion that I chose for myself. MacOS+Parallels does not meet this bare minimum criterion of being trustworthy.

This is the problem in a lot of privacy communities… People make up criteria that are not realistic and not based on reality. All what you have posted so far shows that you just see something being closed-source and immediately say “it must be backdoored/untrustable”, and then go harass other people for mentioning them. You have not provided any technical arguments so far. Just because you like open source software shouldn’t mean that you cannot acknowledge that there are things certain pieces of closed-source software do better. I would much rather have someone go over the strengths and weaknesses of each setup like @TommyTran732 does than having this.

3 Likes
40

ChromeOS’s Questionable Encryption | PrivSec - A practical approach to Privacy and Security

It probably doesn’t matter for most people, but yanno… It’s something to know about :sweat_smile:

5 Likes