Policy Manager GUI: Why, How, What?

General Discussion
1

Hallo! Per GitHub #6166, I have been tasked with designing a Policy Manager GUI for Qubes. As such… I ask the community: 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?

What tasks could you see users endeavoring—and how could those tasks be broken-down in language built around a user’s thought-processes (like, “I need to create a rule preventing myself from copying files from this one VM to those three VMs that present unique adversarial risks to the other one—or, at least, requesting permission for those three VMs, but not requesting permission for any other VM?”)

Sidenote: the above is one of the very few examples I can think of off the top of my own noggin, for how Policies in Qubes work. More than anything, I need more and better examples.

Fire away! I will check-in every now and again, but would prefer to mostly lurk and ask questions. :slight_smile:

2 Likes
2

maybe what follows is useless, but…

list policy rules

  • per destination appVM
  • per source AppVM
    (so I can visualise what I am doing)

option to default policy (in case I break something)

add policy rule

edit policy rule (left click)

hints explaining behaviour when hovering mouse pointer

1 Like
3

When you’re on Qubes OS, one can get an overview of available policies using e.g. ls /etc/qubes-rpc/policy/ in a dom0 terminal. However, there are lots of files because they reflect the possible RPC calls.

Therefore, here are some (more or less useful) examples of those policies:

  • When plugging in a new USB keyboard or USB mouse, I will be prompted to confirm that I want to use that input device (qubes.InputMouse policy)
  • My mail VM is allowed to request GPG key operations from my vault VM (qubes.Gpg), while all other VMs need an explicit confirmation for that
  • All VMs are allowed to access a newly started DispVMs to let it convert a PDF file (qubes.PdfConvert)
  • All VMs with a tag ‘backupable’ are allowed to store files in my non-networked backup qube automatically, any other qube needs an explicit confirmation (qubes.FileCopy)
  • No VM except for my SSH VM is allowed to request SSH key operations from my vault VM (qubes.SshAgent, see this guide on Split SSH)
  • There are lots of more possibilities, e.g. it would be possible to allow one VM to pause/shutdown/kill another VM, interact with block devices, etc. (which I haven’t tested)

More info about the policy in the docs: RPC Policies | Qubes OS

1 Like
4

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.

5

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.StartApp and 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
6

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… :slight_smile:

7

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:

823×375 24.2 KB

3 Likes
8

As a side-note, this will change in the next Qubes version: Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS

9

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
10

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
11

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. :wink:
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
12

Didn’t know about that. Thanks for the pointer :slight_smile:

13

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.

14

I totally agree. Ideally a user would be able to use such a thing without even knowing what an RPC policy is.

2 Likes
15

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
16

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. :slight_smile:

Tomorrow I’m diving deep into learning about allthings RPC with Qubes, so wish me luck as I begin this design project…

1 Like
17

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:

18

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
19

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