Not persisting QubesIncoming

User Support
1

Hello,

I’m working on a project where files are exported from a vm to an offline ‘viewer’ VM, and then copied from there to an ‘encrypt’ VM which will encrypt the files and then copied to a ‘send’ VM.

I have 4 VMs:

  • app (online, tor only, don’t want to install any extra software)
  • view (offline, with libre office etc installed)
  • encrypt (offline)
  • send (online)

I’ve got everything working, my only problem is that I’d like the view/encrypt VMS to discard any files that were processed after the Qube is restarted.

Based off How to make any file persistent (bind-dirs) | Qubes OS I understand that /home comes from the appvm rather than the template, and so /home/user/QubesIncoming is persisted between restarts.

I thought there might be some way of marking my ‘view’ and ‘encrypt’ VMs as ‘disposable’ but as far as I can tell you only get a disposable VM if you specifically ask to open a file or copy a file to a disposable VM - by default /home is persisted.

Does anyone have any suggestions on how to proceed? My current thought is to have some kind of custom script that just does rm -rf /home/user/QubesIncoming on shutdown/startup but that seems a bit crude.

Thanks in advance

2

Update - I just spotted Fully immutable qubes with whitelist of persistent folders - #7 by deeplow which is basically the same question - except in this case I don’t have anything I want to persist.

3

Just to be clear, for the view and encrypt VMs:

  1. You want data in QubesIncoming to to be deleted between reboots.
  2. You want other data to persist between reboots (e.g., your Documents)
4

/home/user/QubesIncoming can be a symbolic link to '/tmp/QubesIncoming`.

3 Likes
5

edited

2 Likes
6

Sorry I wasn’t clear enough. I don’t actually want any data to persist between reboots. I do however need the vms to be able to be sent multiple files per session, so a workflow could be:

  1. User on app vm reading lists of files, exports a few of them to viewer vm (by clicking an export button which runs qrexec-client-vm view-vm qubes.FileCopy) - there will be more than one export operation per session
  2. User views some files on view vm and sends a few to encrypt VM - again in multiple operations

I think disposable VMs would be good for this but I need to be able to predict the name of the VM so that the ‘app’ VM is able to qvm-copy commands (the name of the ‘view’ VM is currently hard coded into the ‘app’ codebase). Since disposable VMs tend to be called e.g. disp1234 I’m not sure how that could work. I also have a user policy that allows copying from app to view to encrypt, I’m not sure whether you can write user policies for disposable vms.

7

Thanks so much, that will definitely work! I’ve got a second question I guess which is if I don’t care about any persistence between reboots is there a way of using disposable VMs for this task?

8

If you symlink only the QubesIncoming folder, some data may persist.
Such as thumbnails of opened files (e.g. /home/user/.cache/thumbnails/).

What you are looking for is called named disposable.
https://www.qubes-os.org/doc/disposable-customization/

3 Likes
9

Thank for the clarification.

In this case, you should be able to set up a named disposable VM, similar to how sys-net and sys-usb can be disposable. This will also allow for the name of the VM to be consistent and known.

1 Like
10

Thanks @szz9pza @sm95 - named disposable was exactly what I needed, all working now