Qubes ready to install for Journalist-Human Rights workers

As the author of this repository, I’m open to any and all feedback. I’ve been very intrigued by @unman and their project here: Simple set-up of new qubes and software

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.

2 Likes

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.

Sorry, I’ve been away. Does this post refer to me? If yes, I am completely lost on it.

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.

Sorry for the extended and scattered response.

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.

1 Like

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?

For curious

Just search for ESU patch

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

Aren’t they?

Summary

[user@dom0 ~]$ sudo dnf search windows

======================= 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

Here’s what I have so far:

$template_base.sls

$template_base:
  qvm.template_installed:
    - name: $template_base

clone.sls

builder_requisite:
  qvm.template_installed:
    - name: $template_base

qvm-clone-id:
  qvm.clone:
    - name: template-builder
    - source: $template_base

clone.top

base:
  dom0:
    - match: nodegroup
    - $custom_qube.clone

config.sls

/path/inside/qube/to/install/file:
file.managed:
  - source:
    - salt://$file_pwd
    - user: user/root
    - group: user/root

/home/user/.rpmmacros:
  file.managed:
    - source:
      - salt://builder/rpmmacros
    - user: user/root
    - group: user/root

#https://github.com/QubesOS/qubes-builder.git:
# git.latest:
#    - name: <https://github.com/QubesOS/qubes-builder.git>
#    - user: user
#    - target: /home/user/qubes-builder

config.top

base:
  builder:
    - $custom_qube.config

create.sls

include:
  - $custom_qube.clone

qvm-present-id:
  qvm.present:
    - name: $custom_qube
    - template: $template_name
    - label: $label_colour

qvm-prefs-id:
  qvm.prefs:
    - name: $custom_qube
    - memory: $min_ram
    - maxmem: $max_ram
    - vcpus: $vcpus

qvm-features-id:
  qvm.features:
    - name: $custom_qube
    - disable:
      - service.$service

"qvm-volume extend $custom_qube:private $custom_private_size" :
  cmd.run

update_file:
  file.prepend:
    - name: /etc/qubes/policy.d/30-user.policy
    - text: qubes.Gpg * builder sys-gpg allow
    - makedirs: True

create.top

base:
  dom0:
    - match: nodegroup
    - $custom_qube.create

install.sls

# vim: set syntax=yaml ts=2 sw=2 sts=2 et :

{% if salt['qvm.exists']('cacher') %}

{% for repo in salt['file.find']('/etc/yum.repos.d/', name='*repo*') %}
{{ repo }}_baseurl:
    file.replace:
      - name: {{ repo }}
      - pattern: 'baseurl=https://'
      - repl: 'baseurl=http://HTTPS///'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]
{{ repo }}_metalink:
    file.replace:
      - name: {{ repo }}
      - pattern: 'metalink=https://(.*)basearch'
      - repl: 'metalink=http://HTTPS///\1basearch&protocol=http'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]

{% endfor %}
{% endif %}

install:
  pkg.installed:
    - pkgs:
      - qubes-core-agent-networking
      - qubes-core-agent-passwordless-root
      - qubes-gpg-split
      - aspell
      - aspell-en
      - createrepo_c
      - createrepo_c-libs
      - debootstrap
      - devscripts
      - dialog
      - dpkg-dev
      - fedora-packager
      - fedora-review
      - g++
      - gcc
      - git
      - gitg
      - gnupg
      - m4
      - make
      - perl-Digest-MD5
      - perl-Digest-SHA
      - python3-pyyaml
      - python3-sh
      - re2c
      - reprepro
      - rpm-build
      - rpm-sign
      - rpmdevtools
      - systemd-container
      - texinfo
      - wget
      - vi
      - zlib-devel
      - ${packages}

install.top

# vim: set syntax=yaml ts=2 sw=2 sts=2 et :

base:
  $template_name:
  - $custom_qube.install

$custom_qube.spec

Name:           $name
Version:  	$version
Release:        1%{?dist}
Summary:        Salt builder template

License:        GPLv3+
SOURCE0:	$source0

%description
$description

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}/srv/salt/build
cp -rv %{SOURCE0}/*  %{buildroot}/srv/salt/build

%files
%defattr(-,root,root,-)
/srv/salt/build/*

%pos
qubesctl state.apply build.create
qubesctl --skip-dom0 --targets=template-builder state.apply build.install
qubesctl --skip-dom0 --targets=builder state.apply build.config


%changelog
$changelog

I just have to figure out:

  1. Where to put the various sls and top files for it to work
  2. Create a bash script to populate the variables
  3. Maybe create a fancy GUI dialog box that does this too
3 Likes

/srv/salt?

1 Like

…and make them actually work properly :stuck_out_tongue:

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.

If the standard WINE is either difficult for what you want to do, and or you have money for your use of Windows. You might look at the CodeWeavers site. Run Microsoft Windows software on Mac, Linux and ChromeOS | CodeWeavers

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.

{% if salt['qvm.exists']('cacher') %}

{% for repo in salt['file.find']('/etc/yum.repos.d/', name='*repo*') %}
{{ repo }}_baseurl:
    file.replace:
      - name: {{ repo }}
      - pattern: 'baseurl=https://'
      - repl: 'baseurl=http://HTTPS///'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]
{{ repo }}_metalink:
    file.replace:
      - name: {{ repo }}
      - pattern: 'metalink=https://(.*)basearch'
      - repl: 'metalink=http://HTTPS///\1basearch&protocol=http'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]

{% endfor %}
{% endif %}

The {% %} delimit control structures, and {{ }} variables
If there isn’t a cacher qube, then none of that code reaches the
evaluated state.

Good to see salt getting more attention in Qubes.

1 Like

I’ve spent the last month on that repo, studying it religiously. You’ve done really well with it.

They’re simple once you figure it out :grin:

Qubes OS “Qube Maker”

Template Builder
Salt Script Generator
Automatic Provisioner

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! :slight_smile:
  • 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 :slight_smile:

———-

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….”

1 Like

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.

4 Likes

May I PM you?

I just PMed you.

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.

4 Likes