(Opt-in) service for copying files to AdminVM

[rootkovska]

An opt-in service (probably just the extension to the standard qubes.Filecopy) which allows copying files to the Admin qube. By default the policy for this service should be:

$anyvm dom0 deny

... and the administrator should be expected to add one or more exceptions above the default deny rule, such as:

work-email dom0 ask
work-itl-repos dom0 ask
$anyvm dom0 deny

The files should land in the Admin qube's ~/QubesIncoming directory (note the user might not be named user as is the case for the default template VMs).

Rationale

We've been avoiding opening up an easy way for users to copy files into dom0 (AdminVM qube) for years, arguing there should be no need for this, while at the same time recognizing this as the opportunity for users to shot themselves into the foot badly. At the same time we've been using dom0-verified-RPM-packaging to deliver the necessary packages to dom0 (e.g. updates). This model has worked well for most cases.

But some scenarios, especially those involving customized commercial extensions for our paying corporate customers, require sometime the need to deliver some files to dom0, at the very least the definition of (non-public) repositories together with verification keys (which are different from the repos/keys used for the public Qubes packages, naturally), hence this ticket.

Relation to Qubes-wallpaper setting service

This is somehow related to #215, but neither service can replace the other: the wallpaper-setting service should involve automatically converting the image file to a trusted one (via Qubes Image converter) and automatically placing the resulting (trusted) image file into a directory where it could be easily selected as a wallpaper, while the file copy service discussed here should not be touching or examining the file in any way, just place it into ~/QubesIncoming. We should think how to prevent users from discouraging people from (ab)using this service for wallpaper setting though.

Relation to GUI/Admin split

In Qubes 4.1 we plan to move GUI out of the Admin qube (#833). This service should support copy to both GUI and Admin qubes, and both should be disabled by default (via deny policy).

[DemiMarie]

I think we should also add an additional prompt, requiring the user to do something non-trivial to confirm the action.

[DemiMarie]

I think we should also add an additional prompt, requiring the user to do something non-trivial to confirm the action.

[rustybird]

If Filecopy is going to* run in dom0, it might be a good idea to add a mode that restricts filenames to ASCII. Accepting arbitrary bytes in filenames makes me nervous even just for VM-to-VM copy.

* Right, it kind of already does... but only for the updatevm (which can be a DispVM).

[rustybird]

If Filecopy is going to* run in dom0, it might be a good idea to add a mode that restricts filenames to ASCII. Accepting arbitrary bytes in filenames makes me nervous even just for VM-to-VM copy.

* Right, it kind of already does... but only for the updatevm (which can be a DispVM).

[fosslinux]

@rustybird very good idea

[fosslinux]

@rustybird very good idea