Default-dvm using split-gpg2 using Tags

General Discussion
1

I was messing with the RPC policy to get all DispVMs created by default-dvm to use split-gpg2.

In the guide server-qube and client qube is used. I used gpg-server and gpg-client.

First I went for:

qubes.Gpg2 * @anyvm @anyvm ask default_target=gpg-server or qubes.Gpg2 * @anyvm gpg-server

In addition to creating a config file the template that backs default-dvm and adding sudo bash -c 'echo "gpg-server" > /rw/config/gpg-split-domain'

Then I tried the same with Tags since I was thinking it’s a pretty wide net using @anyvm to ping my gpg-server. Am I right in thinking that a compromised VM could make requests to the gpg-server with the above policy?

With Tags the following worked well, and I’m thinking it gives far better isolation. That led me to think that it could be a good idea to update the split-gpg2 installation guide using this approach. If not, I’m happy to take on any comments or observations.

  1. Install split-gpg2 package in template for default-dvm and enable Service split-gpg2-client in default-dvm.
  2. Tag default-dvm in dom0 with qvm-tags default-dvm add gpg-client. Now every DispVM spawned by default-dvm will inherit the tag gpg-client.
  3. Update policy file in dom0 (/etc/qubes/policy.d/30-user-gpg2.policy) with:
# Allow only tagged VMs to ask to connect to gpg-server 

qubes.Gpg2 * @tag:gpg-client @anyvm ask default_target=gpg-server 

# Explicitly deny every other VM 

qubes.Gpg2 * @anyvm @anyvm deny

This gives a pop-up to confirm any request between a tagged gpg-client and the gpg-server. I guess it could be a PITA to some work flows. If so, a more convenient approach without the pop-up (as long as the VM has the gpg-client tag), but less secure would be:

qubes.Gpg2 * @tag:gpg-client gpg-server allow
qubes.Gpg2 * @anyvm @anyvm deny

Would I be right in thinking that this approach gives far stricter isolation? Any disadvantages?

The original policy from the guide needed deleting to prevent conflict. Delete: qubes.Gpg2 + client-qube @default allow target=server-qube

And an additional tag was needed if you plan to keep the gpg-client laid out in the guide. qvm-tags gpg-client add gpg-client

In addition, I found that assigned tags can be inspected in dom0 with: qvm-tags --list | grep gpg-client or qvm-tags default-dvm to check individual VMs.

I’d love your input and opinions. Many thanks.

1 Like
2

Correct, I almost exclusively use tags to better control isolation. Managing setup complexity is a downside, but qvm-tags list and the policy manager are your friends. So yes, I agree that you’re making good use of the Qubes tools and improving the security of your gpg-server.

2 Likes
3

That’s just my opinion but the current document is quite a mess so, I don’t think it is a good idea. What I would like is a good resource on tags (a “How to use tags”?), so that, combined with How to edit a policy it makes it easier for a user to achieve what you did (with links provided as a hint in the Split GPG-2 guide). I’m trying to rewrite the latter with some examples.

I don’t understand why it conflicts. Is that something that could be fixed in the guide?

qvm-ls --tags gpg-client instead? qvm-tags needs a VMNAME argument first. list (not --list) is the default action.

1 Like
4

Me neither. I just found requests to the gpg-server through tags were not accepted while the original policy in the guide was in place.

Thanks for the link and the correction. I took the wrong note. qvm-tags default-dvm works fine.

5

Maybe related to the order?