The post contradicts with Qubes Security Model . I understand it. - This post is more for “Qubes Enthusiasts.”
I embarked on this project at the beginning of March and have since spent over 50 hours exploring this manager. Now, I’m seeking motivation to continue. I welcome all feedback, and if you appreciate the concept, please consider giving the repo a star.
As a Qubes Enthusiast, I evaluate my risk of serious cyber threats as considerably low. However, I enjoy using Qubes, and I find that its usage motivates and energizes developers to enhance it further. This, in turn, helps those who genuinely need Qubes, unlike me. On the flip side, I feel a certain lack of flexibility for my regular use, and I see immense potential that is currently underutilized due to its complexity.
Another driving force for me is the realization that, with the current lack of certain software, I risk discontinuing the use of Qubes in the future. As of now, I am highly motivated, but I’m not confident that I’ll maintain the same enthusiasm to debug the unikernel installation on dom0 five years from now.
Trust growth: This is the most important and singular task. The aim is to simplify it for easy revision, sign it, and improve connections with other Qubes projects.
Bug fixes
Your understanding and support are appreciated as we aim to make Qubes more user-friendly while maintaining its robust security.
Can you ellaborate what exactly this thing does? I checked screenshots on github, but still what exactly happens when user wants to install “Windows installation (currently, only Windows 10)”? Because installation of Win10 is not that easy process after all.
There is the video demonstration of Windows 10 installation. All credits for so streamline installation go to elliotkillick with his qvm-create-windows-qube tool.
I’m somewhat unhappy with this being incorporated in to Qube Manager
-it feels like the wrong place. But the principle is right -
that’s why I demoed the “Simple tool” last year, which also includes a
mirage-firewall install.
It seems wrong to me to automatically install a new key in to dom0
without any warning - even when it belongs to as obviously trustworthy a
person as me.
I’m not sure that I agree with making it easier to install 3rd party
templates than official templates, and to use a different GUI tool to do
it.
At the moment, anyone wanting to install one of the templates I build
can either download the template, as explained here, or add
the repository to the qvm-template tool, so 3rd party and official
templates are managed together. This feels right, and either approach
puts the user in control.
But the aim of making Qubes more user-friendly is absolutely right. I’ll
be interested to see how this develops.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Your tool was certainly a key reference for my project, and I had intended to mention it in my post but couldn’t locate it immediately.
Qubes-manager served as an ideal starting point for me because it already provides a frame that works flawlessly within QubesOS. I was able to easily replicate the qubes-admin logic from existing functions and redesign UIs as needed in QTEditor. That’s the main reason why it’s incorporated there for now.
Regarding certificate installation, I initially aimed to prompt a pop-up on the first run to explicitly inform the user about the necessity of increasing the size of QubesOS volumes and installing certificates. However, I decided release what I had at a moment as I started to lose motivation.
Your instructions were immensely helpful! If you examine the code, you’ll notice that your instructions are essentially encapsulated within a Python wrapper. I greatly appreciate your work!
Here’s why I designed Qubes-fancy-manager this way:
Ease of Installation: PyInstaller allows for a simple executable file. (Appimage didn’t work as I wanted) It doesn’t add anything to dom0, maintaining minimal presence in the domain. The only change I made was adding it to the system-tools menu. My goal is to achieve following level of simplicity in installation:
Afterwards, it should request permission to add itself to system-tools. If users want to install your templates, it will separately ask for certificate approval.
Ease of Use: I’ve amalgamated your scripts, mirage-firewall, and elliotkillick/qvm-create-windows-qube under a Python wrapper for simplicity. If you’ve seen the YouTube video on Windows installation, it’s as easy as choosing a name for the qube and clicking “ok”. The same applies to mirage-firewall and your templates.
Cleanliness: I’m striving to perform all operations in disposable VMs. My preference would even be to create temporary volumes on dom0 for downloading debs, all while maintaining air-gapped security.
ONLY_IN_DREAMS_FOR_NOW: I imagine to have a simple repository system, somewhat akin to helm in k8s (I am devop). The vision is for anyone to be able to create a package, host it on a git repo, and users can then install it effortlessly by importing this git repo url. However, I acknowledge that this is huge contradiction to QubesOS’s isolation principles. Hence, my idea is to introduce a system to differentiate between the sources of these packages.
Incorparated in installation tool
Green would be reserved for instructions from the QubesOS team official docs.
Yellow would indicate contributions from very trustworthy users such as you or elliotclick.
Orange would be for current installations from enthusiasts that are deemed to be reasonably trustworthy. Require user explicitly import the installation
Red would be a zone where the user can add a link to a git repo, representing the highest level of user discretion and potential risk.
These principles I was thinking to make the tool user-friendly, maintain integrity in QubesOS, and to respect the great work done by those who support 3rd party images, making installations more accessible on QubesOS.
[user@dom0~]$qvm-create-windows-qube -n sys-whonix -oyw -i win10x64-enterprise-eval.iso -a win10x64-enterprise-eval.xml anon-win10
[!] ISO not specified
[i] Available ISOs (Make sure to download them with Mido as instructed in the README):
win10x64-enterprise-eval.iso
[user@dom0 ~]$
i dont have github because its javascript and microsoft and no account with tor
!
Green would be reserved for instructions from the QubesOS team official docs.
Yellow would indicate contributions from very trustworthy users such as you or elliotclick.
Orange would be for current installations from enthusiasts that are deemed to be reasonably trustworthy.
Red would be a zone where the user can add a link to a git repo, representing the highest level of user discretion and potential risk.