Considering how some of the larges data breaches have happened, I don’t think the insurance contracts are that specific. One of the snowflake breaches happen because the person was downloading pirated video games, and got inflected by an info stealer, on the same laptop they used to log into the backup infrastructure, and they didn’t use MFA.
“The best of the best of the best, sir!”
“With honours.”
This is a good point. Given the broad spectrum of types of work machines (on-site workstations, kiosks, take-home laptops that can go off-site, VMs that employees remote into, servers, thin clients, anything else…?):
- What category of “work machine” would Qubes OS best fit in its current state?
- What tweaks could be make you make Qubes OS (or a version of Qubes OS) better fit the use cases for any of these categories?
———
-
Most definitely, in all cases, remote management, automation, and some kind of way to remotely maintain a Qubes OS machine would be needed.
-
Tutorials that are NOT someone recording themselves on YouTube for an hour
, would also be helpful. Preferably interactive ones, that either could be overlaid on top of Qubes OS, or come built-in. -
Policy enforcement would also be helpful. For example, the ability to lock down certain
qvm-features, or “stuff in the Qube Settings panel”.- In case a work machine was stolen (and unlocked),
qvm-copyto/from certain Qubes could be disabled “by your organisation” (or something along those lines). - Maybe it might be possible to implement this in a way that “protects” the work stuff, while also allowing the user the standard freedoms in all other aspects of Qubes OS (personal qubes, etc.)?
- In case a work machine was stolen (and unlocked),
-
Remote LUKS decryption (or something that performs a similar function)
- I have managed to get dracut-crypt-ssh working in the initramfs on one of my testing machines a while back. Still works….
Is there anything else?
4 Likes
Qubes is by its very nature highly adaptable, since it’s just a VM platform. There’s already a foundation for Windows, OpenBSD, and more, but the big issue is its hardware cost since it’s expensive to run.
A cloud-like version of Qubes would be nice, where a server dishes out VMs to terminals that are little more than input devices and a monitor. Maybe even just a Raspberry Pi all-in-one keyboard + monitor or less (e.g. ultra-specialized, ultra-simple hardware that make the terminals unhackable). These are no longer node- or edge-devices, but literally terminals.
There won’t be just one VM per terminal, but as many as the user needs, within the bounds of her access and resource privileges; and each terminal can be serviced by multiple servers, compartmentalized by sensitivity, with multiple redundancies. As long as the Pi or monitor isn’t compromised, everything stays segregated. EDR or other such extra protection, if needed for whatever reason, become a lot more feasible with this configuration. Access control should also be simpler, and copy-pasting / moving files between sensitivity levels can be configured.
From the user’s point of view, the UI/UX is simply whatever they’re most familiar with–typically ‘click thing; get window’, except these windows have Qubes borders. They can even do riskier activities on their corporate terminal like inspecting malware or running unsanctioned executables… with the right setup.
I have never done corporate or even plain server networking, so this is ‘baby’s first sketch’. Someone somewhere probably already built what I described about decades ago.
If remote management is to be included into Qubes, I’m fairly certain the Team will have to make a big show of excluding it from their consumer products, otherwise, on top of being a big security target, the paranoia and conspiracy theories will never end (cf. your Intel vPro thread. Fantastic post by the way).
Back after a few days of absence. A very interesting conversation going on. Actually I am busy with concepts of whatsoever security stuff (or crap). Security is quite a business of IT about everywhere. So I will add a few more flavors to this very conversations and pick some comments
-
incompatible hardware issues of Quebes-OS
I dont really think there is any as long as you know what you are dealing with. A XEN hypervisior (XEN compatible stuff required). Usually I will HAVE to get certified stuff for whatever product with regard to projects of IT-business. Basically the same “problem” with any product. There is no proper support without it is there? I just started Qubes-OS recently. Gave it a try. Ran into issues. Figured I just got XEN as well. Figured technical requirements. Problems solved. Any system requires specific hardware. I am aware of systems which will literally run on ANY hardware, but this is way about compiling and well. Not my cup of tea for tests I am using Qubes-OS for. Additionally I wouldnt do that anyway. Would go for those vendors who sell Qubes certified hardware. Maybe a Nova. Different topic. -
customizing
So it does take a lot of time to get Qubes customized. People who are aware of dealing with VMs in general will be ok. People who are aware of docker, kernel virtualization in general, will be more ok.
→ most people wont be ok -
organizing vs. custom
I think documentation is quite good. So there is one key part. How to deal with those funny cubes in general.
Those examples are actually great and reflect a common problem. Raising questions like. What do you want? How much time do you want to spend to get something done? How do you actually work?What do you know about security?
Mainstream questions, right? Yet awareness is quite on the rise. Companies who had been affected (well, infected) by security issues, companies who know companies who have been affected. -
onboarding complexity
So I will just refer to previous aspects. Usually I either meet people who either lack sense of security or are deceived by a funny tool. Any tool is quite useless without proper onboarding.
So Qubes-OS can be quite simple, or way complex. Yet it should be useful for the one who uses it. -
Who uses Qubes-OS?
Actually I will try to get back to first question again. How to get more attention? I am still happy with my Qubes-OS PoC which is entering enterprise-level. As far as I am concerned it’s techs (nerds and so on) who fight for security. Simple fights like - NO! I WOOONT USE WHAT*****APP. Try this instead please.
This fight sounds simple. This fights sounds simple to be resolved with regard to security. It isnt, is it?
So when I read that Snowden is using is, people of the press, developers, maybe even freelancers, I think Qubes-OS just needs more people of that level to speak or post. Stress pros. -
Get rid of wishful thinking
Any hypervisor wont enable a cool gaming experience.
Any mean of security takes skill or backoffice. Security is about tools and advanced concepts.
No solution is perfect. Someone wrote that Qubes would be at risk if a machine was unlocked and accessed by another one → any product is. Usually it’s a security incident if someone didnt lock a machine BEFORE leaving it. Even if it was just to get a cup of coffee. Just a minor example.
Anyway, lots to read and bad me didnt read everything since my last post. I will check these posts next time. Quite an interesting community. Gotta check hardware-token vs. Qubes next though.
2 Likes
Yes. That which is “not so fine” as you said, is by design. 
The answer is rather simple: because the devs aren’t interested in to get more attention from big players.
Topic solved (even in General Discussion subforum).
Patience, young grasshopper. All in good time. One day… 
Oh for sure! When I say “remote management”, I mean “opt-in”, fully transparent to the end user, revokable at any time, ideally contained within a single qube, etc.
For example:
- Being able to restrict a qube from things like:
- local resources, such the global clipboard or USB/PCI passthrough
- user-defined networking (eg. enforcing a compulsory VPN/tor for a work qube)
- excluding a qube from being able to execute functions such as
qvm-move/qvm-copy(or restricting which origin/destination qubes are permitted) - a way to lock down certain options in the qube settings panel or
qvm-prefswithout a password/key (a secondary use for split GPG, maybe?
) - a way to have LUKS encryption on individual qubes (which can already be done now, but have it more integrated in the qube settings panel)
- potentially with remote approval for unlocking - Any other thing that seems to be common-place among work-managed devices.
I (and I would imagine that quite a few people) would be alright with loading a qcow2 or an LVM container containing a work-managed work qube onto my Qubes OS machine if I knew that:
- It couldn’t see, nor interact with, my own stuff
- I could choose it’s network access method
- I could delete it at any time
…just like a work device, more or less 
I would never even dream of wanting any of this to be part of a vanilla Qubes OS install. NO WAY!
But just like we don’t want anyone interacting with our machines unless it’s on our terms, neither do companies. They have to treat their own employees as guests as part of their threat model.
Just like bring-your-own-device remote connections work, they need to be able to revoke access to their stuff at their discretion. That might be a local qube, a remote qube, a VPN connection, various aspects of the qrexec protocol, or any other aspect of the machine.
And there are definitely ways of achieving this in a way that is transparent to and “respectful” of the end user
Thanks, but I had no idea that it would become the behemoth it is. 
One thing that could definitely be possible with “Qubes in the Cloud”: GAMING 
3 Likes
You want attention from… Google of all people? 
bruh.
Mainstream attention is bad. It leads to systematic enshittification and corruption in projects. Please keep corporate capitalism and its cursed army of sheeple far, far away from muh qubes.
PS: fun fact: Google was initially funded by DARPA and as such has been an arm of U.S. navy intelligence since its very inception. I’d avoid it like the insidious plague that it is.
1 Like
Just to add my .02. The fact that every major journalism/news outlet (in the west, many in Europe) use SecureDrop is a major win for QubesOS. (And many are beta-testing the SecureDrop workstation which runs in Qubes.) Dangerzone and similar “products” help to establish the OS as a major platform with plenty of potential for adaptation and wider appeal.
2 Likes
You definitely make a valid point. In anything, once you start including the full spectrum of demographics, you inevitably end up getting those who detract from it.
But it’s usually outweighed by the benefits brought by the other demographics you include
Agreed. Definitely not going to happen. 
Definitely, and this is the demographic I had in mind when I talked about remote management and locking down.
I’d imagine, at the moment, only the hardcore nerd journalists using Qubes OS are able to troubleshoot autonomously, which leaves a huge portion of users dropping it at the “it’s ‘not working’…” stage.
These people need a way to be able to reach out to someone for their Qubes OS conundrums, in a way that not only matches their level of technical understanding (i.e. some of these journalists might not be comfortable/familiar with asking a question on this forum, let alone be able to understand/action the response we provide), but also fits their threat model (i.e. asking for help doesn’t put them in danger).
These are the same users that might inadvertently pwn themselves while trying to perform their desired tasks. They might not fully understand why a certain methodology is required.
Can you train them up and equip them with knowledge? Sure. But that takes a lot of time, and they have to really want it…
Most people show extreme reluctance to absorbing a concept at a level of abstraction/complexity that is beyond what they perceive to be sufficient for their own application. (in plain English: “Why do I need to know how to use the terminal if I can just point and click…?”)
This is often why you get the “that’s a lot of unnecessary steps to achieve the same result” response. That “same result” they refer to is subjective, unfortunately.
These are the same people who will access a website over Tor/VPN, log into that website with identifiable information, and then not understand how the website knew it was them.
If I was responsible for facilitating someone like that in performing a task safely, and I could reasonably foresee them doing something silly like this, I would defintely want to do everything I could to protect them from it, until they were ready to step up and go deeper in their level of understanding (which might never happen at all).
For situations like that, I would definitely want to be able to lock down certain things until they were ready to understand them.
For example, I would definitely want to deny them from using qvm-copy to get files out of “secure_qube” and into a Windows HVM, just so they could edit the documents in Microsoft Word, because they “felt more comfortable with Microsoft Word”, and didn’t realise that they just pwned themselves.
That’s the aim of this. To protect them until they are ready.
If something like this existed as a transparent opt-in add-on that the end user fully understood, I could see it having a net positive impact on Qubes OS adoption as a whole. I could see more people giving it a go.
…as long as it’s done right …
2 Likes
Because to the average user, their experience is going to be along the lines of:
ok I have multiple browsers that I don’t need that all run slower than my old OS, why do I need this?
I’d also like to mention that popularity doesn’t necessarily mean intelligent users. Yes, something like Kali is popular, but how many of those users are the same people posting to forums How does gaem on Kali Linux liek a hacker??!?!?!?!!
The point is, Kali is popular with those who need it, and goal should be Qubes-OS to target the demographic who needs it, not just the big players who’ll bring not the intelligent users Qubes-OS needs but more-so the commoners joe who’ll fill up the forum asking why we can’t just run games on dom0 where the GPU sits.
2 Likes
Who says it already didn’t?
ok we’re f 
ing doomed
Qubes team playin’ with fire
1 Like
One of the most common reactions you get when you explain Qubes OS to someone… 
Definitely true. Very good point.
Probably the same people who believe that this is real
Definitely, but if that demographic gains a few new members in the process, then hey, why not
Imagine, one day, you could get a “free Qube” on AWS, Linode, Akamai, DigitalOcean, or your homelab…
It can already be done. Just needs a framework…
I can boil a pot of water in my oven, or cook steaks on my car engine, because that’s where the heat is.
It takes fifty times longer, uses twenty times the energy, and is an infinitely more painful experience, but it can be done…
Same argument. Same themes. Same answer. Every time…
Possibly, but I have to admit, some of the topics sound really cool:
| Topic | Pros | Concerns | Reaction |
|---|---|---|---|
| Qubes OS as a Vagrant provider | Would provide users a choice between Ansible, SaltStack, Vagrant, and whatever else is out there on the interwebs. | Business Source License, restricts to “non-production” use, which could mean literally anything their lawyers want it to… | Skeptical, but interested to see what comes of this. |
| System Health Monitor | Builds on existing GPL code, uses existing libraries. | Could potentially become the systemd of Qubes OS  |
Interested to see what comes of it |
| Mechanism for maintaining in-VM configuration | Improvements and closing of exploits in qrexec, which is always nice | Might not be easy to do (properly) in 175 hours…  |
What’s the worst that could happen? The results aren’t as good as what is currently in the codebase, and they’re dropped… |
| Qubes Live USB | Would make “trying” Qubes OS so much easier | *clears throat* Death By USB Controller Passthrough  |
Been done before, but there’s always a way to do something better than last time |
| LogVM(s) | Anyone who has designed production infrastructure will agree that it’s always better to have logging done on another machine | Could introduce parsing sanitisation error exploits (if you allow any software to write arbitrary strings to the logs) | Worth investigating, and a step in the right direction |
| Whonix IPv6 and nftables support | The option for IPv6 in Qubes OS (without having to manually configure it) would be nice | IPv6 can pwn you if you do not understand it fully… | It’s inevitable. At some point, IPv6 will become standard, and Qubes OS will need to be ready for this… |
| GUI agent for Windows 8/10 | YES! YES! DEAR GOD YES! Just to have something remotely functional would be nice for anyone who is “forced” to have a current Windows installation handy | You are more likely to have a threesome with supermodels than have Windows Defender like the code that you’re testing |
A necessary evil, and someone’s got to do it… |
| GNOME support in dom0 / GUI VM | Variety is always nice | Variety brings extra complexity | Expect pushback from the KDE Klan and i3 community |
| Generalize the Qubes PDF Converter to other types of files | Very useful for people with a target on their head 24/7 | Has to be done right, or could lead to regressions and introduction of exploits | The ability to flatten/sanitize other filetypes would be nice |
| Progress towards reproducible builds | Would be lovely to be able to build the latest ISO without doing a month of debugging | Can’t think of any | N/A |
| Porting Qubes to ARM/aarch64 | Raspberry Pi, Snapdragon laptops, almost every smartphone in existence, and Ampere CPUs in data centres could get some Qubes OS love | Extra workload for everyone to maintain multiple versions of Qubes OS | PowerPC/RISC-V/s390, anyone? Maybe later |
| Android development in Qubes | We could end up getting qubes-android-tools, which would be cool |
Extra codebase, extra work | Qubes Andoird Template! |
| Admin API Fuzzer | Spot more vulnerabilities with less effort | Extra infrastructure to maintain | Sounds good |
| Secure Boot support | Would help some people/companies/entities meet their IT audit targets | Proprietary blobs in Qubes OS. Hopefully they don’t contain bugs… | Another necessary evil, unfortunately… |
| Reduce logging of Disposable VMs | Would make disposable VMs even more disposable, which can be good | Hopefully it’s user-configurable | Disabling Firefox Suggest in DispVMs is a good start  |
Some really interesting projects there. Nice!
Fun fact. It is because of the GSoC that we have our beloved Qubes Template Manager.
1 Like
Exactly. I wans’t objecting/complaining, just pointing out non-awareness. Although, I’d prefer we got simple, normal functional keyboard layout switch over QTM. 
1 Like
1 Like
@fsflover, you never fail to deliver 
2 Likes