As to how I have one suggestion: at some point when the user is adding/editing a policy let them click and drag VM names from somewhere else on the screen so they can be used as targets/sources for the rules. No matter how much work gets spent on the gui policy manager, if I have to add 5-6 VM names to a rule using current vm selector I will just not bother.
Why:
- Know what policies are available
- Know the target of those policies
- Know the source of those policies
- Configure all three without using a text editor
How:
- I’m able to quickly inspect by policy: for each policy, show source VM, target VM, action[allow/deny/ask]
- I’m able to quickly inspect by VM: for each VM, show policies it can or can’t perform on other VMs; show policies another VM can or can’t perform to it
- I’m able to see system-added vs user-added policies: make it harder to screw my system up because I was messing around with
qubes.StartAppand now nothing works
To be quite honest, a static graphic that just shows the relationships would be more useful to me than configuration. Configuring policies creeps into “you must know what you’re doing if you decide to mess with this” territory. I rarely bother with Qubes-RPC config after things are set up the way I want.
1 Like
What are the human needs and motivations behind some of your policies on your own machines? If that makes sense. Hearing some of those in folks’ own words, would help me a great deal.
Like: Why do y’all setup a policy, and what value does it bring to you (vs to your machine)?
Which isn’t to say I don’t understand all of the great feedback so far. I do, and it’s necessary! It’s just also helpful to make usable and intuitive experiences, to break down problems to speak to human needs and motivations. Thx for all the rad feedback thus far! Keep it coming… 
What could or should this thing do? How could such a GUI deliver value to you? How might you anticipate such a GUI delivering value to other users?
Use-cases
Multi-level Security / Group-based security
At the very essence, I think this is what a new user could want from these tools: help me organize my machines into groups. And then separate those groups. Not sure if everyone agrees, though.
In academia, Qubes is sometimes referred to as a Converged Multi-Level Secure (MLS) System. In theory, these systems are structured into trust levels.
Qubes does have some mentions of this in the documentation, like:
However, one should keep in mind that performing a copy and paste operation from less trusted to more trusted qube is always potentially insecure, since the data that we copy could exploit some hypothetical bug in the target qube.
But since this is not enforced by default, one just ends up having qubes copy and paste from other qubes more or less at random. It would be cool if such a tool could help the user organize their Qubes into levels.
Or in the very least organize qubes into “domains” (different from the term “dom” in “dom0” – in the Qubes sense of domain). For example, putting qubes into the same domain would allow for RPC communication between these but restrict by default from other domains.
Feature ideas
Visualizer
Being able to see a graph where the qubes would be the nodes and the possible policy connections as edges could be great to understand if we did any mistake.
Each edge could then show how many times that policy for those qubes had been used. (you can get a list of actions by running in dom0 journalctl /usr/bin/qrexec-policy)
I made a very basic mockup of this a while ago:
3 Likes
As a side-note, this will change in the next Qubes version: Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS
The motivation behind it is defining inter-vm access control.
For example, we want to be able to run service command XYZ in qube A, as long as it came from qube B.
But, qube A or B could mean “any template VM” or “any disposable VM”, or even dom0.
What this currently translates into is knowing how to specify the source VM, target VM, and the action [allow/deny/ask] at a low level (Qubes-RPC policy file in /etc/qubes-rpc/policy/).
The value a GUI would bring is easing the selection of source/target and not having to know specific Qubes-RPC syntax.
The other value a GUI would bring is turning those low-level Qubes-RPC policy files into a graphic that clearly shows the inter-VM access control that is currently being enforced.
I still believe mucking with policy files are a power user activity or one-time actions a normal user might make while trying to configure something. I like the recent discussion around salt-based distribution to alleviate users from even having to bother with policy files. That’s why I say a graphic would probably have more value for most users, and the subsequent ability to add/update/delete policies the power users would appreciate.
2 Likes
Personally, I consider Qubes to be an application for the Biba integrity model, where each compartment (a VM in our case) is given an integrity level and a set of categories.
2 Likes
Fyi:
[1] also supports RPC policy graphs for visualization. I however won’t make them editable.
@deeplow: Arrow thickness based on usage would indeed be nice though.
Honestly I used my own program wrt policy stuff only 2 times or so. I checked whether it looked right, found no issue and noticed that there’s simply nothing much more interesting in the policies. The defaults simply work quite well. 
It’s nice for verifying though.
But well, maybe I’d customise the policies more if they were more accessible…
[1] GitHub - 3hhh/qvm-ls-mermaid: Qubes OS network & RPC graphs
2 Likes
Didn’t know about that. Thanks for the pointer
The value a GUI would bring is easing the selection of source/target and not having to know specific Qubes-RPC syntax.
The other value a GUI would bring is turning those low-level Qubes-RPC policy files into a graphic that clearly shows the inter-VM access control that is currently being enforced.
YES. Exactly. The above is a basic premis of most control panels. 1 : “Let me modify settings to configure My Thing,” and 2: “Let me get a broader view of All My Things to see how those existing details are shaping my experience in this moment.”
That said… @deeplow’s mockup feels extremely detailed and shaped around features to serve a mental and informational model that is neither obvious nor intuitive to me. Which is not at all “a negative,” just many more steps ahead from where my brain is at right now, with seeking to build a thing that will be intuitive to all users (which yes, is entirely possible and important to strive for, with complicated domain-knowledge intensive stuff).
At the outset of tackling an entirely new realm of UI functionality, “Feature” level detail ideas of UI particulars feel more distracting then helpful for shaping the current need, which is developing an information and interaction model. Comments by @icequbes1 get more at what I’m looking for, but still feel theoretical.
If you all are comfortable telling me in this forum about policies y’all have set up on your own machines—and to tell me about those things in the format of “I have a policy prohibiting my Personal VM from copying files to my Work VM, my Banking VM, and all Template VMs, because I work with my most sensitive document there” that would help me the most. That format covers 1. What the rule is, 2. Origin VM, 3. Target VM, and 4. Motivation/Benefit behind why. Once I get a better sense of how everyone does their policies, I’ll be better poised to devise a UI.
Alternately, the team@research.qubes-os.org email has its encryption key on the Team page on the qubes website. If that kind of information is sensitive, I"d love if folks wouldn’t mind sending me those details for their own machines, there. THAT would help me, more than anything, tbh.
I totally agree. Ideally a user would be able to use such a thing without even knowing what an RPC policy is.
2 Likes
I have a great WHY for you: up until now (that I’ve stumbled over this topic by chance) I wasn’t aware of the various uses of “Policies” in Qubes. A GUI will help users be aware of this feature and maybe/hopefully will also help them by providing best-practice or commonly-used examples. My point of view is that Qubes should be more accessible to the “common-folk” type of users, and I believe that GUI (with examples) will help and ease them into Qubes.
1 Like
Yes, Yes, Yes, aaaand, more Yes! Everything you shared is why I love getting to work on this project as a non-developer ux contributor.
Tomorrow I’m diving deep into learning about allthings RPC with Qubes, so wish me luck as I begin this design project…
1 Like
Good luck! I have a recommendation for you. Instead of diving into it through the documentation read instead the blog posts. In my view it’s much more gradual an non-technical than the docs (relatively speaking):
Of this post only these sections should be relevant enough:
I need to find the spec for what is being released in 4.1, and cannot find that. I’ve already read the blog articles, and appreciate the suggestion—TY!
While I can absolutely “teach myself,” hearing from users is also really important—which was the objective of this thread. Hearing from people in human terms, to learn about how their own mental models work.
1 Like
This one, perhaps?
Not exactly a spec but the general outlines are there.
edit: Ah, just read that you had read those blog posts. So perhaps this is not what you were looking for. Anyways, leaving it here for others.
edit2: also, @ninavizz shall we make this a pinned post for a while so you can collect more feedback?
1 Like
I agree with the already expressed opinion, that I would use such a program mostly for evaluating existing policies, because a graphical visualization is better suited for spotting (mis)configurations and relations across multiple or large configuration files.
What I would wish for in such a interface would readily accessible information on which config file/ config lines the visualization is based on. So for example a little frame pops up upon mouseover or clicking some ‘i’-icon and shows the corresponding configuration lines.
That way it would be easy to double check whether the program interpreted the configuration files correctly and teach the user about the inner workings of the policy system.
While having a nice graphical interface is necessary groundwork, it is even better having a userbase that is not too dependent on nice graphical tools. Graphical tools that help average users step by step to understand how things work under the hood help greatly pursuing that goal.