I’ve gotten a lot of very helpful answers so far from folks—thank you all!
Between this and other threads, I now know more about the technical ins-and-outs of Policies, than I think I could ever desire. Looking forward to now talking to my cats in qrexec syntax.
What more I need from you all, is simpler “I need this to do that” sorts of statements, around how you all use policies. Use cases. Which I appreciate to be a difficult question to ask, because “Policies” in and of themselves are a nebulous category of technical permissions. So, to re-frame the question in more human terms…
How do you all restrict your own clipboard permissions?
Not “technically how,” but as you might explain the value of this feature to your parents.
How do folks here use Split GPG?
In 1-2 sentences, without syntax or function details; how might you explain this if you were selling Qubes devices?
Do you have set “guardrails” around which VMs can save files to/from one another?
How would you summarize this use of that policy service as a “use case” to a friend?
Do you run updates over Tor? If you are comfortable explaining this, why does this functionality have value to you?
Do you run automated backups? Automated retrievals? Share your use-case of why this functionality has value to you.
How do you all restrict your own clipboard permissions?
I don’t, but I can see how this would be useful:
a) restrict ability to copy from “secret_stuff”
b) restrict ability to paste into “shady_stuff”
… kind of forcing me to move information explicitly inside a file,
which I am much less likely to do by accident.
How do folks here use Split GPG?
with mail qubes (to sign & en/decrypt)
with development qubes (to sign git commits)
Explanation: you remember how your phone sometimes asks you if an app is
allowed to use the mic or the camera? It’s like that, but every time a
qube wants to use your GPG keys. And that app/qube gets to never
actually access your keys.
Do you have set “guardrails” around which VMs can save files to/from
one another?
I use the “ask” setting, which means if a qube wants to send a file, I
get a dialog in dom0 telling me about it and asking me where to route
the file. I can also cancel, in which case nothing happens.
Do you run backups over Tor?
No, sorry got nothing about this one.
Do you run automated backups?
I wouldn’t know how to. I do run a full backup every night to an
external hard disk, but also don’t see the connection to policies. Sorry.
Other stuff I actually do with policies:
set the InputKeyboard and InputMouse to “ask” … I know what I just
plugged in and whether that was an actual keyboard/mouse or not.
set OpenURL and OpenInVM to “ask” … as I described above, it gives
me the “do you really want to? …and where to?” ability, including:
launching a new disposable qube
route to any already existing disposable qube
routing/starting any other qube
change my mind and “cancel”
making my updates happen with a specific proxy qube (tor, cached etc)
Bottom-line: that “ask” dialog where you can cancel or choose the target
qube … it could be prettier but really it is my number one poster
child for the power of Qubes OS.
Yes. It’s a security feature. Basically, updating over Tor makes it harder for an adversary to target me, specifically, with a malicious/blocked update, since the same update would have to be distributed/blocked to/for everyone.
Partially automated. A script that I manually start, otherwise unattended. Could be set to run automatically via cron job, but I choose not to. Value is simply in making it easier to perform regular backups. I can start my script then go live my life while my machine creates the backup, verifies it, splits it up into smaller chunks, copies/uploads it to my desired destination, and logs the whole thing while pulling out any errors, so I can be sure it actually happened correctly.
As for the larger question, it’s very important to perform regular backups and verify that they can be restored, since not doing so can easily lead to data loss. Inexperienced computer users typically don’t understand the importance of backups until they personally experience some kind of devastating data loss event (and sometimes not even then). It’s an interesting human psychological phenomenon. Moreover, even users who make regular backups often don’t verify that they can be restored. But a backup that can’t be restored is worthless, so this is also an essential step.
The other one was already pinned on all forum pages. What I’ve done is move this discussion into its own thread because otherwise folks would probably miss the goal. Now it’s in the title and this topic is now the one pinned on all pages. @ninavizz fell free to edit the title of this new post.
I have a USB mouse and I set the policy to allow it without asking.
I have configured automatic opening of links from my email-qube and instant-messaging-qube in a disposable VM, so my policy allows those VMs to start corresponding dispVMs.
Oh, I just assumed she meant updates, because “backups over Tor” makes no sense. (The closest thing would be uploading backups over Tor, which would be even less relevant to this topic than what was actually asked. )
Yes! Another team I work with had the same question. I’m thinking of suggesting that functionality go into the Settings window for individual qubes. Where might you expect such a setting to live?
I think this is not straightforward. Let’s say, I receive a couple of emails/intant-messages with links in some qube. I click on them and they are opened each in its own dispVM.
Do I want this or do I want them to be opened both in a single dispVM? It probably depends on how much I trust the senders and the linked websites. I don’t think I will ever want to apply “opening in the same dispVM” by default unless (1) I have not enough RAM or unless (2) opening a dispVM is annoyingly long. In the (1) case, such option would probably be useful. I expect that it could be shown in Advanced qube Settings, probably with a hint that it may decrease your security/privacy but save RAM. In the (2) case, I would very much prefer that the following issues are solved instead:
Note, that I can always simply use ctrl+c, ctrl+shift+c, ctrl+shift+v, ctrl+v instead and open the second link in the first dispVM in this way. Anything more complicated/flexible than that might be useless.
At this point I am sure to annoy someone, but here goes:
If you set the policy to “ask” you will have the choice for each and every file (OpenInVM) and URL (OpenURL)
Your options are:
start new dispVM using dispVM template of your choice
use already running dispVM
use (and start) any other qube
cancel
You have this choice every time you open a file or URL! How is that not the default? (I know, not advocating to make my preference the default, but man this is handy)
I loved that you brought this up for SD, and the solution you proposed!
@Sven I totally agree with you and hope to put this policy’s setting option in the individual Qube’s setting pane. Seems like the best place to surface it. Looking forward to getting a version of this stuff into a prototype and in front of users.
Also, I’ve used policies to share the screen of one AppVM into another. This is useful when you want to do a presentation from your work qube, for example. But the designs you’ve been working on are on your other qube. It’s not as safe, but possibly better than installing the fully bloated zoom client on the qube where you stall all your creations. See:
I also use policies to have to be able safely use zotero ( a reference manager). I don’t particularly trust Zotero. So what I do is having a zotero qube where I store public documents fetched from the web via the zotero browser plugin (1-click local web page archiver – super convenient). And then I have an offline qube you can think of it as a notes-vault where I do my note-taking. When I click a citation on my notes-vault it selects that document on the other qube’s zotero. The communication between these two is very very minimal. Just the document id is passed, not even the document’s titles.
(before someone asks, I don’t have this in a shareable form. It’s just for personal use. But extremely simple to replicate.)
The other way around I created the SecureDrop issue first and it was on the back of my mind and what motivated me to seek a solution.
It’s completely unclear to me what questions you are answering, because
I cant identify the message you are commenting on.
For this, look at using qubes-app-shutdown-idle which will
automatically shutdown a qube when there are not open windows.
You can edit the timeout period in the configuration file ( by default 5
minutes)
)