What about a more casual qubes?

General Discussion
1

I was wondering what if there was a more lighter qube with less security features and focused more on streamlined virtualization for fun

once ive daily driven qubes i just cant stop admiring how flexible, streamlined, useful, fun and challenging it is. Qubes doesn’t just provide security but a lot of other features that makes other linux distros obsolete for example i have so much flexibility and control over my device i wouldn’t really need gentoo
the backup is slightly more tedious than nix if not as good
it provides stability to arch which if you break it, you dont have to worry
it provides enough challenge if not more than gentoo but without having to deteriorate your sight to install it
having multiple neofetches and flexing it feels really nice (even tho i didnt rice it)

but when people look at my qubes they consider like im crazy paranoid guy and start interrogating me for my use case and threat model, i just jokingly tell them i buy bathwater with qubes ;3 but that is far from the truth as i just wanted challenge, utility, efficacy to utilize my good hardware.

this is just a thought experiment to observe qubes without taking into consideration about the security since the mass seems to assume qubes is for the paranoid and take a look.

3 Likes
2

obviously there are more advantages and features to qubes but my brain is not braining so i cannot pick them all off the top of my head

1 Like
3

Use any linux distribution and run your stuff in virtual machines. Performance will certainly be better and it’s less cumbersome than Qubes OS.

2 Likes
4

Your question is like my comments.

Very cumbersome of Qubes os is passwordless-root.
This is not able to KVM, if user uses lightweight Qubes os by KVM, user must enter password all VMs.
So usability of Qubes os is very good, but user can not choice any init system and distributions on Qubes os, user have not freedom of init system choice.

2 Likes
5

One setup you can try is Parallels + Windows VMs. You have seamless mode and all that. GPU acceleration is very good - it is actually fast enough to run Half Life 2 and stuff at max resolution.

I am also not entirely sure if it is even worse than Qubes security wise, there are a few trade offs.

The good:

  • Verified boot. At minimum, the main OS is verified by the boot policy so it is not entirely unprotected like Qubes rn. (Qubes AEM hardware requirements are so bad that the only thing that satisfy them that I have found are are old, dead Skylake laptops. Trenchboot is supposed to fix this but the only thing that has changed so far is TPM 2.0 support, and even that doesn’t seem to be ready yet).
  • Disk encryption is handled by the Secure Enclave and the encryption key is never stored in RAM.
  • Rate limiting to fight brute force attempts is done by the Secure Enclave.
  • Less weakening of the guest’s security. To have UI intergration with Qubes, VMs run X11, which makes any sandboxing attempt inside of the VM completely futile. Parallels doesn’t do anything like this to either Windows or Linux VMs, although only Windows has seamless mode.

The bad:

  • No PCIe device passthrough.
  • USB devices you add goes directly into the host first before being passed through to the VMs.
  • macbooks do not have memory encryption.
  • No fancy chaining of proxy VMs and whatnot. VMs are all connected to the same emulated VLAN.
  • That also means no firewall VMs to enforce the firewall rules and whatnot.
  • You also need to be careful with settings in Parallels, because by default it does stuff like allowing the guest to run apps on the host. Gotta disable those if you do not want VM breakouts.
  • Clipboard sharing is done less securely than on Qubes. You have bidirectional syncing, sync from mac to the VM, or disabled.

I am not sure about the strength of Apple Virtualization + Parallels Tools when configured properly compared to Xen + qrexec on Qubes.

I switched from using Qubes as my daily driver to using the Parallels (with a few UTM VMs for stuff like NTS) setup about a year ago - so far I have not regretted it. I still have to come back to Qubes for Whonix because Tor on ARM Linux is not very well maintained at all - it is 6 months out of date by this point. I am much, much more happy with the macOS + Parallels though as this setup has verified boot, GUI acceleration, and is just generally less buggy.

4 Likes
6

To begin, I’d like to note the point of Qubes, what may be counterintuitive, is not “to have everything virtualized”. Let’s take a look at some of the articles and posts by Joanna Rutkowska.

As I’ve emphasized over the years, the essence of Qubes does not rest in the Xen hypervisor, or even in the simple notion of “isolation,” but rather in the careful decomposition of various workflows, devices, apps across securely compartmentalized containers. Right now, these are mostly desktop workflows, and the compartments just happen to be implemented as Xen VMs, but neither of these aspects is essential to the nature of Qubes.

Before the development of Qubes OS started, this decomposition could well (although with its own disadvantages related to security and user experience) be implemented with distinct Windows user accounts and distinct Integrity Levels: Running Vista Every Day! | The Invisible Things Blog

That said, the decomposition is even nowadays commonly implemented with distinct Unix accounts acting as domains, e.g. running a web server as an unprivileged www-data account. If this amount of security is sufficient, then one could reasonably easily implement the mechanism of disposable compartments by a simple script that deletes the contents of a user’s home directory and recreates it from a tarball as part of a login process.

Back to the question regarding a solution

focused more on streamlined virtualization for fun

what does this mean in the first place? I could think of the following:

  • a setup where the clipboard is always shared between virtual machines, so that there’s no need to securely pass its contents from one virtual machine to another one
  • a setup where 3D acceleration is realized through Direct3D/OpenGL passthrough
  • a setup that allows mounting an ISO file and already having an unattended installation script, rather than relying on building a template
  • a hypervisor that’s type 2 and runs as a usermode application inside an operating system, therefore having less strict hardware requirements

If I didn’t get any of these right, please clarify.

However, maybe there’s a totally different case. This part, to be precise:

but when people look at my qubes they consider like im crazy paranoid guy and start interrogating me for my use case and threat model

If there’s a social problem of any sort, like harassment, then it’s a different case than doing things related to both workflow decomposition or using virtualization software for fun. Solving such a problem is out of the scope of this forum, I believe.

2 Likes
7

It’s proprietary. How can you reliably estimate the security of it? You should expect them to use xor for encryption.

1 Like
8

I really do not buy the “something is proprietary therefore its not trustworthy and something is open source therefore it must be trustworthy” argument. People do security research into proprietary software and find exploits for them too, you know.

You really gotta prove that it is somehow less secure - by pointing out exploits, issues in the architecture/implementations, etc.

You can’t just make up something like “they use xor for encryption” without anything backing it up. What I do know for a fact is that with a Qubes install on any reasonably modern hardware right now, you don’t have any kind of tamper protection at all so an attacker can just backdoor your initramfs or something and that would be it. You also have to think about the fact that there is nothing to ratelimit brute force attacks, that stuff like systemd-cryptenroll entirely trust the TPM to protect its internal state (unlike how Bitlocker or ChromeOS encryption works), and that the encryption key stays in memory while the computer is running, too.

2 Likes
9

Yeah, I know. But I stick with the encryption experts’ opinion, that if something is proprietary (actually, closed-source more importantly), then the reliability of its encryption should be considered as reliable as simple XOR.

I said you should expected them to use xor.
Meaning you cannot and should not rely on it more than on xor.

If something is close-source, it’s their responsibility to prove that they use proper encryption. Because I or anybody else cannot check it myself. So, if they cannot or do not want to prove is, it is only safe to consider it having garbage encryption that is badly implemented with mistakes.

About “tamper protection”. Some think, that when your working device gets in the malicious physical hands, then you already lost.

1 Like
10

Yeah, I know. But I stick with the encryption experts’ opinion, that if something is proprietary (actually, closed-source more importantly), then the reliability of its encryption should be considered as reliable as simple XOR.

Which “expert” says such a thing? Please let us know of their name and credentials :rofl:

If something is close-source, it’s their responsibility to prove that they use proper encryption. Because I or anybody else cannot check it myself. So, if they cannot or do not want to prove is, it is only safe to consider it having garbage encryption that is badly implemented with mistakes.

Not how anything works

About “tamper protection”. Some think, that when your working device gets in the malicious physical hands, then you already lost.

It’s not easy to carry out those attacks against a Pixel, iPhone, or Macbook. You can’t just magically tamper with things like the initramfs and expect them to not give a boot error.

2 Likes
11

I do not want to convince you. You can further blindly rely on unverified and not audited close-source solutions and call proprietary stack MacOS+Parallels+Windows more secure than Qubes OS.

1 Like
12

So you are refusing to say which “expert” claims Filevault is about as reliable as a simple XOR? That’s what I thought. :clown_face:

I never made any claim which stack was more secure. I wrote down plenty of issues with the macOS + Parallels setup in my original comment. And I have no clue about the strength of the hypervisor to protect against VM breakouts. I went out of my way to stress that in my original post.

With that being said, I am trying to answer OP’s original question regarding a setup similar to Qubes with “more streamed line virtualization for fun” with some objective assessments. Now you gotta derail the thread with these ridiculous claims. So unfun. :sob:

Look at this incredible “unverified and not audited closed-source solution” you mentioned that definitely no one has had a formal look into:

Man you really need to stop making stuff up as you go.

Oh, and here is a counter example: ChromeOS’s encryption is open source yet there is something very sussy wussy going on. I was actually going to suggest ChromeOS + crosvm + Borealis as another fun virtualization setup to play around with and mention that the encryption is sus (with real technical proof). But since you are here, I wonder if your “encryption expert” :rofl: can tell us what is wrong with their open-source-therefore-must-be-trustworthy encryption implementation?

2 Likes
13

@TommyTran732
Sorry, all I see in your post is a clown emoji.
Life is too short to have discussions with toxic people.

2 Likes
14

Let’s get this straight:

  • You came in, tried to spread FUD by saying the encryption is about as reliable as a XOR
  • You made up claims that some “expert” said such a thing and that you listen to them. I asked who the “expert” is, you don’t have an answer and just went with “I am not trying to convince you”.
  • You repeated the unsubstantiated claim that Filevault somehow has to be considered garbage, and made up the whole part where it is “unverified and not audited”.

:eyes: I see what you are doing. This is just an attempt to gaslight people into believing that if something is proprietary it must be untrustworthy garbage. You can’t actually back up any of the claims you made, so you just do the classic “I am not trying to convince you, now feel bad using your very sussy wussy piece of software”. I just pointed out where you obviously lied about the “expert” and I am somehow am the toxic one.

2 Likes
15

With an open source project, there’s going to be a substantial element of not trusting proprietary software by default here and challenging that is probably off-topic. It’s still interesting to see solutions involving proprietary components, though.

2 Likes
16

The way I see it, it is a security project. People should assess things based on actual technical merits and not go around making things up. The last thing you want is that the forum misinforming and misleading people seeking security with FUD.

2 Likes
17

I think that’s an overstatement of what was said. Treating opaque encryption as if it’s xor is a fair representation of common reasoning for preferring open source components - if you can’t actually get at the technical merits to assess them then assume bad things by default.

Yes, it’s a security project that’s maintained an open core policy throughout (some nuance here and also see “where it is possible to use it an open source boot firmware ought to be more trustable than a closed source implementation.” further down), but provides integration support for proprietary systems. I don’t think I’ve seen any stronger statements.

2 Likes
18

It’s hard to assess these things from the technical side. In the end it’ll boil down to the non-technical question of “trust”.
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.
When comparing similar closed source software A and open source software B you will also weight the amount of trust you can put in the people/company behind each software that they implemented the software features properly but you can also verify that open source software B is really implemented the features that it was claiming (aside from the question whatever these features were implemented properly without bugs which is up to the first question of trust).
Now with open source software B we can at least have something technical to assess.

5 Likes
19

Treating opaque encryption as if it’s xor is a fair representation of common reasoning for preferring open source components - if you can’t actually get at the technical merits to assess them then assume bad things by default.

Except people do get to the technical merits of Filevault 2.

“where it is possible to use it an open source boot firmware ought to be more trustable than a closed source implementation.”

I will argue that this is antiquated thinking and doesn’t really hold true. Here is a quick example regarding to boot firmware when compared to the proprietary UEFI firmware:

  • Coreboot + SeaBIOS → Clearly less trustworthy. You have no way to implement SRTM. An attacker can just attack your boot stuff and it’s game over. You can try to implement DRTM like with Qubes AEM, but that requires trust in BootGuard (to prevent malicious firmware from being flashed and compromise SMM) and TXT, which are proprietary technologies.
  • Coreboot + EDK II → Maybe better, if it is regularly updated, has all of the security features the proprietry counterpart has, and has BootGuard to protect it. An example is NovaCustom with their EDK II firmware - it might be okay after their next update where they will blow the BootGuard fuse, but in its current state without BootGuard it is just worse than what normal laptops have.
  • Coreboot + Heads → It’s trying to do SRTM but there is no root of trust. There’s this circular logic which I do not think makes it very trustworthy in actual use: How exactly is HEADS/Pureboot secure? - All around Qubes - Qubes OS Forum (qubes-os.org)
  • Libreboot → Terrible, has a history of doing anti-security stuff like blocking Microcode updates.
2 Likes
20

Maybe we should create a new topic for the question whether or not open, or closed source software is better… I am not even sure if this question is related to the forum itself…

5 Likes