If I could find and tweak the salt scrips involved it might make easier the adoption of Qubes for journalists. I’d be keen to configure this for our use.
Agreed. I’m only attempting to anticipate what journalists might need and to what they are accustomed. You’ll note the dom0 upgrades are purism-specific and aren’t meant for other hardware.
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
: windows
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
structures.
@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
Anyway…
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
directory structure.
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
updates.
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
know.
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.
Imagine the “Create new Qube…” GUI dialog box, but with a few extra widgets at the bottom:
Something like the current “Qube Settings…” dialog box, but with a few additions
Users could select from a list what packages they’d like installed in their Qube
Standard distribution repos
The Qubes OS repo
Users could potentially put in the path to custom repos (or even DEB/RPM/ZST/eBuild packages) to add to the list
Any package not in the standard repos (maybe the actual maintainer’s repo is a few versions ahead of the distro repo)
Sysadmins/software devs could include their own bespoke packages (corporate internal software, etc.)
Users could specify additional things like:
Custom config files
Anything else that Salt scripts let you do (assuming a decent enough UI can be made for it, and I’ll do my best)
Users have the option to:
Build a template/Qube based on that config
Build Salt scripts based off Salt templates, based on that config
Both
Why do this?
It allows anyone to provision custom AppVMs (they might be based on predefined Salt templates, but that would still be enough for most people)
AND share them with the community!
Would be a massive time-saver for sysadmins in provisioning work machines
Instead of “I created this awesome Qube, you should try it, here’s the entire 15GB template backup”, it becomes “I’ve created this awesome Qube, you should try it, here are the 400KB Salt configs”
Allows for more transparency when the community shares their customised AppVMs/Templates
Would likely be easier to use for more demographics than manually typing them out (journalists and HRDs and their bosses is a good example)
Could potentially even be as simple as cloning the “Qube Settings…” dialog box and reconnecting the widgets to a backend that generates Salt scripts
———
I’ll do up a UI and post it to show you what I’ve got in mind
———-
Here’s an example of my first try at making Salt files:
Yes, they’re probably a bit cringe, but this is likely the end result if a regular user could be bothered to give it a go….
A GUI tool to auto-generate these based on pre-made Salt templates would go a long way in making Salt in Qubes OS “accessible to the masses”.
———-
That was what I was struggling with. Thank you!
That’s what I have been doing.
I will once I get up to speed on that actual directory structure. I’m getting there….
Thats what I’ve been basing the scripts off.
That explains a lot. Thank you!
It’s very powerful, but requires a lot of text-based config, which puts it beyond the point where a lot of regular Qubes users would go “Nah, couldn’t be bothered….No GUI tool….Too difficult….”
I hate to revive this threat, but the transition to R4.2 shows why Qubes OS is not ready to install for journalists and human rights workers. VPN no longer works. The desktop environment is different. Some applications are XFCE and different from Gnome. Where did text editor go? Oh, it’s now mousepad!? Suddenly there’s a new learning curve.
I had separate conversations in the recent weeks with human rights people working with those living in hostile environments. Everyone needs Qubes OS. And yet none of the persons who spoke to me said Qubes OS is usable. Certainly note for helping people in difficult environments to install it and use it.
For Qubes OS to be usable by journalists and human rights workers, a dedicated non-profit organizations needs to be set up to provide ongoing support / training / coaching to the end user.
Edit / addition: I have great appreciation for the work of the Qubes developers. I certainly do not want my posts to discourage them. When I post, I consider myself as a Qubes advocate. I have offered to train some hr orgs on Qubes after using it for many years now and I keep mentioning it.
I, too, am rather shocked by the differences. Always game to learn new things, but I may now spend a week getting things back to the way I liked them. I suppose, however, growing pains are beneficial for new users – especially all the dialog and help boxes, like those now appearing in Qubes Global Settings.
I am glad to see you are still using - Qubes that is. Your insights on things Qubes, and implementation(s) is surely going to be useful.
I believe that the Developers did make a good decision on where to stop, and not include software beyond the basic implementation of the qubes for operating systems, was a good decision.
As of now, their decision makes it obvious where the best security point ends.
But that does not mean Qubes is ready for the use of a non-technical person. Particularly someone who has little computer experience, in a desperate situation where they are at risk by a power structure, a government, who has complete control of the ISP, internet structure, for searching security topics.
I think the templates are too bloated (especially in 4.2); minimal (with the necessary packages for sys VMs) should be default. But i understand this lowers the bar for entry to many new users, so im okay with setting up my own slimmer system.
Now that Qubes Builder v2 is out, when I find the time id like to drill further into my amateur salt scripting (perhaps finding external funding for the task) and reevaluate my github repo for journalists. It is a travesty of a work in progress, but i remain committed – if slow. (I think that is just the reality of this space: few hands and a whole lot of work, which places a premium on education before action – a necessary byproduct.)
Ive also engaged the FPF team on their Securedrop Workstation and feel now that if there is to be a broader recognition and implementation of Qubes within the journalism community, it’ll be through them.
Hoping this thread doesnt die … So thanks for reviving.