I must admit that the first thought after I read someone “hardens” Qubes OS (and before diving into “solutions”) is that the key premise of Qubes is lost from the sight: Security by compartmentalization .
Especially when “hardening” includes installing Windows and Kali standalone, and installing software in dom0, like this guy did.
From experience and past communications with some journalism/freedom defenders organisms, trying to get data and help those organizations more directly myself, judgements on their use case is not recommended. Facilitating their use cases is. This is the general problem of enforcing security against needs. If people are not able to do what they intend to do, they will bypass security measures and processes, which outcome is generally worse.
What I read in the previous article is such an attempt to use Qubes to fit a certain “general” use case, which doesn’t go against the compartimentalization for security/prevention mechanisms enforced by Qubes OS.
Hear me out here, having Windows templates, permitting to create Windows qubes with proper compartmentalization, is still desired and requested per certain use cases. Not providing for those use case or judging those needs would get in the way of filling such use cases and requirements. Being able to deploy proper Windows templates for such organizations is not to be dismissed and should still be a priority. That definitely facilitates onboarding, and a really good way to transition out of Windows.
As for your point on installing software in dom0, I did not see anything in the article (WiP as I see) that is really concerning. Installing tlp, instead of powertop, is actually better at controlling power usage since tlp is made to talk better with sensors (again, on newer hardware) from usage from past personal tests, but suggesting tlp usage is again a liability problem for anyone that would decide to deploy that. Again I agree with you that adding software under dom0 is to be made really cautiously, but better hardware control is needed if not using computer on AC adapter all the time. Again, I do not deploy powertop myself for others, but I wish I could, since I receive a lot of messages about battery draining, which would be partly mitigated by powertop --autotune, where higher gains are attained by tlp deployment. But I do not feel comfortable at all deploying patch, make and cups-client that comes with installing tlp in dom0 without further modification.But if one justifies longer battery life to be more important than the risks associated in having those risky tools into dom0, who am I to judge. Ideally, those risky tools should not be deployed under dom0. Again, the problem there is not tlp itself, but forced dependencies and automatic download of such dependencies. And the liabilities into deciding for a user which will not witness such dependencies and will be unaware of attached risks. But we must agree that having 7 hours of battery time vs 3 is impactful to say the least and might be needed in some use case. Fact to remember is always “it depends”. And this is where things are complicated.
From my experience and communication with groups that would desire to deploy such pre-packaged deployment, liability issues are the main problem as of now for anyone trying to pre-deploy anything prepackaged. Those organizations have problems endorsing the usage of some software versus the other, and prefer to let the user choose for himself, to not have any liabilities.
So I would go to precedent posts recommendations as well. The need, now, is to get data points from journalists. Some organizations are willing to have some of their employees participate in such a focus group.
They are also interested into having Qubes deployed for journalist’s day to day work. But as you can imagine, the prior use case is way more easy to scope: the goal is to get SecureDrop submissions and be able to deal with those in a really confined way, permitting to deal with untrusted files and producing output that is exportable without compromising source related information in any way. An isolated workstation that never leaves a confined area, for that specific scenario. Going further and for them to suggest/propose/deploy or create deployment guides and/or salt recipes for such a vague “journalist” use case scenario comes with all those liabilities. And having experience of my own into deploying such applications and customized workflow myself leaded to many challenges to say the least, leading me to reduce the customizations and the pre-installed software myself, leading to more support time with the majority of the customers.
As said in other posts on this forum, I think the end solution might be a mix of the following:
extrepo and ext-repo-offline being deployed and back-ported to Qubes repo in time. Now available into bookworm unman’s debian-12 template. This will permit documentation to fill the gap of enabling custom repositories securely.
working caching update proxy (cacher project from unman being fascinating solution), well tested and stabilized. So that salt recipes that specialize debian-minimal templates are doing what they intend to do and nothing else, reducing liability issues into promoting one thing or the other, while minimizing download throughput required to maintain all those specialized templates (otherwise, having 6 specialized templates for multimedia, redaction, communication, etc will consume 6x the bandwidth which does not fit the bill here for precarious requirements. Nobody has time to wait for the same updates to be downloaded 6x including repository data.)
Have Windows Templates if needed and be able to compartmentalize usage as in any other Templates, including disposable Windows Template.
And then, in parallel, understand and fill the gaps in upstream projects, like extrepo to have the tools required available. Have tlp not depend on make patch mailx?
And then, create salt recipes to address those needs is form of use cases. But we need use cases. And definitely not to judge them at first sight. But understand them, play with them. And come with alternatives that do not change their use cases.
I’m a little late to this, but I’ll say it anyway.
I’ve been looking online for weeks, ever since the start of this thread, for a GUI or web-based SaltStack config creator.
I have not found any, and that’s actually really surprising
I actually want to be corrected on this, so if anyone does know of a solution that can do it (before I attempt to make my own), please please please let me know
Just something that can:
open Salt files and view them in terms of what they do
potentially create your own
The use case for this is so that people like @catacombs (or anyone, really…) have a GUI tool with which they can build and deploy their own custom Qubes, controlling and automating choice of installed software, network Qube, Qube parameters, and everything else
I dont follow your reasoning here, but not at all. The referred article we are talking about is not about Qubes Dev team but
The Qubes dev team may be blamed to not have followed through supporting their windows tools, but following the same kind of reasoning here:
Using windows insecurely is a risk. Will always be. Getting away of proprietary code is desired. So Qubes Dev team didn’t put that as a priority, added to the departure of the Windows guy from the original Qubes team, if I remember correctly. But I am not aware of the details.
No opinion on that. Like I said in my long response already, this is not my place to judge other use cases, i’m just interested to know that it’s part of one.
Please do not interpret farther then what i’m saying:
I do not understand your reasoning here.
I got complaints by customers that didn’t want signal and element repositories deployed, and worried about some behaviors of Windows templates I once deployed. I decided to remove them and not make that choice for them. User got worried to have their machines hit signal.org for repository package information download, the software was never installed by default. Windows template was deployed though, with latest updates installed on top of killick’s script’ installed Windows 10 LTSC standalonevm. I have learned to lessen customizations over time, just tuning defaults to the bare minimum and documenting my changes through wyng-backups tags, deployed and detached signed in a seperate appvm for audits and state restoration. I’m refusing to customize now. But that is not necessary a good thing, that simply means that there is no one size fits all solution, and actually justifies Qubes devs decision:
They refuse to customize and modify upsteam decisions of implementation. Again, my prior point that you totally missed: nobody wants to be liable if something goes wrong.
Remember that pursuit against McDonald’s because coffee was hot? Well. That person wan against McDonald’s because there was no warning on the coffee cup saying that the content was hot. that means a lot on the disclosure companies have to put on their products to not be everyday in court (and also tells a lot about how crazy our world has become). But that is not my role to take a stance here.
Just saying, and restating: liability is a real thing for organizations. Unbelievable the amount of money going in liability insurances and stuff like that. Really a parallel universe there. Peacing out of this blaming game discussion here. Please listen and keep your eyes wide open when use cases are presented and shut down your judgments and just read: through those use cases are blips of persona requirements to consider.
The ones I read under tlp is: I need to optimize my battery life because I am roaming a lot in my daily job.
The ones behind Kali is information gathering having too much tools for their own goods but why not. Other than that, I repeat: suspension of judgments. Keep an open mind and listen to what they are trying to say.
Yet again, i’m no UX expert here, but those use cases are important.
Windows 7 is EOL since January 2020. Qubes developers developped their Windows Tools FOR Windows7, while it was still maintained, and the complete support of Windows 7 requires to install Qubes Windows tools on top of not latest image if no workarounds are applied. A lot of guides (and ink generally) has been spent on trying to workaround Qubes dropping support for windows for lack of internal resource to work on it. That’s the end of that story, where the community tried to pick up the task with relative success until today with tabbit-pro work, that has still not reached Qubes repo, and which carefully write news, clearly specifying that this support, as of now, comes externally of Qubes team. Qubes, not upstreaming the rpms, as of now, shows they are not ready to acknowledge nor take responsibility (liability again…) as of now until complete testing is done on their side first. That shows pretty good judgement from Qubes Devs, which are more on the careful sides of things then pushing edgy features, and I thank them for that.
So your reasoning was: blaming Qubes devs for having a correct implementation when Windows 7 was a thing for a specific version of that operating system, and then having withdrew at some point? Because you read and refer to a post of someone attempting to use Windows7 as a Template, where up-to-date Windows 7 broke things at some point compared to the moment it was developed for?! That is the reasoning I am following. As of today, without tabit-pro’s version of Windows tools, updated to work with recent versions of Windows (including Windows 11), deploying a Windows 7 is totally risky (not recommended at all) the same way you would probably not run Fedora-19 for your dispvm with old versions of everything and some too recent software not running on it, right?
The good reasoning here would be to push forward for support of ReactOS inside of Qubes, for example. But people want to use Windows to deploy software that is pushed by their corporate environment. This might not work under ReactOS. This is why having Windows current version (with updates) support cannot be completely dodged and constantly requested here, over github, everywhere, and as right now, the workaround by community members were to be able to use the Windows tools that was developed for Windows7 and make it work in a somewhat correct way, which doesn’t permit to be used as a template, but can be used as a standalone appvm. That requires the user to clone the template to specialize it and to keep an original, which is not a desired, fully efficient setup under Qubes for compartmentalization. But then the other solution is to force users to have a separate Windows PC. Those users, having that use case, decide for themselves the lesser evil and decide to use Windows under Qubes, which is still better than running Windows on bare metal.
I’m really not sure of where that call for doubting Qubes Devs come from, but it smells a bit like trolling to me. So if this is the case, that was my last feeding of the troll with my time trying to help, not to cause harm. Less judgements, more questions. Judgements normally come from a total lack of understanding. The only thing Qubes devs are responsible for is to have openly dropped official Qubes support for Windows while Windows was still maintained. And they openly justified that everywhere: not a priority, not enough resources, nobody qualified to pick up the work at the time. And then people who had interests into making this work, and doing way more, picked up where that was left and brought it further. I can only say: respect Qubes OS to have dropped the ball if following Windows internals changes was not a priority. And thanks to tabit-pro for their work; I know a lot of people will test Qubes OS when Windows support will be officially back in, with extended support like proper audio and usb support, OEM activation but their deeper internal work which will ease integration of also Android and ReactOS support through emulation support. At this point, its just to be patient and to wait for proper support and another news from Qubes team.
When users continue to use unsupported/unmaintained software, they can only blame themselves, not others.
Thanks for your response. I’d like you to know that I wasn’t judge your approach. Questioning? Probably. But, isn’t that good actually? For example, you proposed Windows standalone, while there is a possibility to use Windows disposable, if Windows has to be used.
But my point was that once we are aware of endless possibilities of Qubes’ compartmentalization and about the need of self-discipline and changing habits at the first place, not that much hardening and additional VMs are really needed with and inside this gem.
Good Windows support was something when Windows 7 was not EOL. Good windows support is in the making, finally supporting sound, usb and private volumes to get back to a state where using Windows as a template will be possible again, as expected, while not error prone nor hackish to obtain.
I just wanted to reestablish facts around Windows support, which passed from qubes supported to community based support in the past years.
Thanks for clarification. It was just that your English was too advanced for me, regardless of how hard (as always) I tried to comprehend it while it wasn’t my first language.
There is still ESU for Windows 7, and (arguably and questionably legit) workarounds to get it?
I will stop rephrasing in posts I do in the forum from now on and will simply post to original documentation.
Here are the known issues for QWT (Qubes Windows Tool) from amazing Killick’s script, including my notes on random issues that happen at install which might require windows reinstallation, problems with creating private volumes (to have Windows as Template) etc:
When tabit-pro’s QWT will be upstreamed to Qubes repositories, it will be possible to talk about installing Windows LTSC versions (I would not be confortable recommending Windows 7, paid support, hacked or not). This requires a bit of patience here for a News to be posted when Qubes is ready, following last article on the matter: Windows integration work in Qubes 4.1 by the tabit-pro team | Qubes OS
======================= Name & Summary Matched: windows ========================
kf5-kwindowsystem.x86_64 : KDE Frameworks 5 Tier 1 integration module with
: classes for windows management qubes-windows-tools.noarch : Qubes Tools for Windows VMs
=========================== Summary Matched: windows ===========================
kf5-kxmlgui.x86_64 : KDE Frameworks 5 Tier 3 solution for user-configurable main
libwmf-lite.x86_64 : Windows Metafile parser library
I have to keep a computer around to use Windows 10, because, I have a few devices that the software to connect to computer is only for Windows. So, despite my frustration with the implications of Windows Operating System security - - - I understand the need.
As a workaround, consider installing a Qube of Ubuntu, and using WINE (Windows Emulator for Linux). Ubuntu because they have a large forum which has folks who have accomplished all kinds of implementations of software, and some advice in many different languages.
Myself, I believe there exists several free software that is a “I Talk It Types.” I am guessing the versions which there is advice on how to use in different languages.
What I would consider an insecure means of trying to use Windows is to do a dual install of Qubes, and Windows. Qubes needs to be all alone on the computer to obtain . . . I think someone else can explain the how of that point better.
Just Qubes, to attain its goals of security, needs to be installed 'Bare Metal" on the computer. “Bare Metal” being the term of nothing between Qubes and the computer but the Firmware which is for that computer.
All of the salt underlying the packages available in qubes-task can be
found on GitHub
The formulas are very simple, use very few salt states,
and some of the Qubes modules.
This is deliberate - I think almost anyone can look at the source and
understand what is going to happen.
This is fine for single packages - I do not configure a full system in
this way. There it makes sense to use templating, pillar data and grains.
If you want to set up a full system it’s simpler to use more complex
@alzer89 I’m not altogether clear on what it is you are trying to do
here. As I’ve suggested I would not use these simple formulas as the
basis for configuring a full system
You can put the files anywhere where salt can find them.
This is configured in /etc/minion.d/f_defaults.conf
By default the Qubes system has /srv/salt/ as the file root for base
You should always try to structure states and formulas using a proper
So installing the builder package creates a directory at /srv/salt/builder containing the source files.
Because /srv/salt is the file root, you can access these files just by
specifying (using a dot) - e.g. builder.install
The default install also has /srv/formulas - there you will find some
of the formulas for qubes - the formulas are in /srv/formulas/base/virtual-machines-formula/qvm, and you can access
them using qvm.
These form part of the base environment - Qubes also provides a
state to create user salt and pillar directories at /srv/user_salt and
/srv/user_pillar - set this up with qubesctl state.apply qubes.user-dirs
These are for personal configurations, and wont be affected by any
You can create new environments with new directory structures, but in
Qubes I’ve never felt the need.
This may be the right approach for what you are trying to do: I don’t
salt has built in support for templating, and uses jinja as the default
templating language. It’s highly recommended on security grounds.
You can use jinja to provide control structures, access pillar data,
grains, and to deal with variables in the state file.
You can see simple jinja used here to deal with cases where there is a
cacher qube in the system.