Installing software not in the repo: copy-and-paste files into template VM?

[George Walker]

I tried copy-and-pasting the Google Chrome installer into my template VM.  I triple-checked my control-c/control-shift-c, highlight template VM's Nautilus window, control-shift-V, control-V sequence and it didn't appear to work.  I didn't believe that it wouldn't work, so I tried again, double-checking my keystrokes, several times.  No dice.  So out of desperation I changed my template-VM's firewall rules, downloaded the installer in a template VM browser instance, and then reverted my firewall rules after I'd d/led the RPM file.

I have established in my last three topics that I am a highly error-prone user, but even so I really don't think I messed up that particular keystroke sequence.  I was able to copy-and-paste between other AppVMs just fine.

What is the correct way to install software, like the Chromium and Chrome browsers, which are not available in the Fedora repository?  Surely secure copy-and-paste would be superior to giving the template-VM network access, no?  

Best/George

[Joanna Rutkowska]

On 12/29/12 15:23, George Walker wrote:
> I tried copy-and-pasting the Google Chrome installer into my template VM.

This won't work. Copy and paste has a limit on the number of characters
and is not designed to handle file copies betwween AppVMs. Please use
the Qubes file copy mechanism. See the user's guide.

j.

[George Walker]

>Copy and paste has a limit on the number of characters and is not designed to handle file copies between AppVMs.

Is this a bug or a feature? (not that the two are necessarily mutually exclusive)  Copying and pasting files is a pretty basic feature of all modern desktop operating systems I can call to mind; is there a compelling security reason not to include it in Qubes?

Apologies for my inadequate lit review.

Best regards/George

[George Walker]

I just checked the wiki, and noticed that both the file copy and copy/paste operations use Xen shared memory, and both seem to accomplish the same security objectives (preventing snooping by other domains, having superior security to employing sneaker-net (i.e. walking with block devices) between air-gapped machines, etc.).  In fact, they use very-nearly the same blurb of text to describe their security.  It sure would be nice if copy/paste were a general-purpose tool in Qubes...

Then again, easy for me to say: I lack the expertise to write such a patch, and you don't accept pecuniary donations.

[Joanna Rutkowska]

On 12/29/12 17:09, George Walker wrote:
> I just checked the wiki, and noticed that both the file copy and copy/paste
> operations use Xen shared memory, and both seem to accomplish the same
> security objectives (preventing snooping by other domains, having superior
> security to employing sneaker-net (i.e. walking with block devices) between
> air-gapped machines, etc.). In fact, they use very-nearly the same blurb
> of text to describe their security. It sure would be nice if copy/paste
> were a general-purpose tool in Qubes...
>

Well, everything ultimately is a just a stream of bits, right? ;)

The problem with X11 clipboard is that there are essentially two
mechanisms for it (simplifying):

1) a passive mechanism, which do not involve the sending app to
cooperate with the receiving app (and this is what we use in Qubes when
we fetch the clipboard from an AppVM)

2) an active mechanism, which involves active cooperation between the
sending and receiving application. This might involve e.g. the two apps
deciding on using some richer format than plain text for clipboard
exchange. This happens e.g. when you copy and paste between two
LibreOffice windows, as well as between two Nautilus windows.

For obvious reasons we don't want to use the latter in Qubes, because it
seems like a great avenue for possible attacks. So, we resort to the
simplest form of clipboard when we fetch and paste it between different
AppVMs.

joanna.