qvm-run only available from dom0?

[johny...@sigaint.org]

When I try to run qvm-run from within an AppVM, I get "Request refused."

Is this by design, for security reasons? If so, I guess that's perfectly
reasonable. I just don't see that fact documented anywhere.

(The demonstration of one of the Xen exploits executes a qvm-run of xcalc
in dom0 from an compromised AppVM, which kind of implies the fact that
such behaviour is normally restricted between AppVM's. If this is indeed
the case, it might be useful if certain commands could be configurably
whitelisted, from a config file in dom0, to be qvm-run between specific
VM's.)

Thanks.

JJ

[johny...@sigaint.org]

Is there any qvm-* command, or other method, to programmatically copy to
the qubes clipboard?

(Similar to my last question, a perfectly reasonable answer might be "of
course not, are you crazy?" due to security concerns. Requiring explicit
dom0/GUI user interaction for clipboard manipulation seems like a good
idea, but I thought I'd ask anyway.)

Thanks.

JJ

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-08-19 05:11, johny...@sigaint.org wrote:
> When I try to run qvm-run from within an AppVM, I get "Request refused."
>
> Is this by design, for security reasons? If so, I guess that's perfectly
> reasonable. I just don't see that fact documented anywhere.
>

Yes, but it's completely user-configurable. You can read all about this system
here:

https://www.qubes-os.org/doc/qrexec3/

Pay special attention to the section titled "Qubes RPC administration." As
that section explains, there's a file where you can enable using qvm-run from
within an AppVM. That file is:

/etc/qubes-rpc/policy/qubes.VMShell

However, before doing this, there is a very serious warning that you should
heed:

https://groups.google.com/d/msg/qubes-users/xnAByaL_bjI/3PjYdiTDW-0J

> (The demonstration of one of the Xen exploits executes a qvm-run of xcalc
> in dom0 from an compromised AppVM, which kind of implies the fact that
> such behaviour is normally restricted between AppVM's. If this is indeed
> the case, it might be useful if certain commands could be configurably
> whitelisted, from a config file in dom0, to be qvm-run between specific
> VM's.)
>

Yes. The action is prohibited by default because it can be so dangerous.
However, as explained above, advanced users can choose to selectively allow it
for certain VMs at their own discretion.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXt1aDAAoJENtN07w5UDAwrS4QAIhHMbWIIY6etJA+ThQ8YhZF
vjwftWCsnRI4B1OeJ+ECNCE9PeMoaIa65HzdDm/X9Vq2yvX1uk4Z3PjFIX4Y/lAk
yhIR6LnStgGHFZJp3uHWXlnT9eXeFpu93MRID1o2enRBrhQAA9+WmkTHyUyCtiu1
z96g4B3xE5faPfOBEhkg3xex4anxt2a5RY8tGo/99hwUHQ5U2stiRkBRmbAm3TUL
PjplajBoNoe8yGS/7m1gCdC7BA3XiSjw2eCjsT3Zshc70tEEd7dFFwBKmPVVURCJ
dTIbfVKk4yCMsM3Vw/V4CZLzTnBPzpwPSmk1ZymJRTedgIBUdQLYpRDb3RLS1vmZ
r44cpZk3Hdkf6ZimFcSk13HYE1LZxvCaDolD/MPeB+EKLzkiNIhlPIkJzDCpCwIy
rOgPuShcF+xf73HR3ZGelLcPl7jVFxphsTu8OC7NG/9NF8X8i7U2ZpzLTW7lPTr4
vISlH7u5woLQ3O4OL10ei0bgDSGnA3osF5LwcU9zc9ZwciHROLd4s9wDrJCIAK9Q
kMaPeasaFv6osRN/XlumxYC7gPC5N86g6lX9ylFXnXTW6yTViylZN2TtcqRdM6VI
0p7C7Rxi+99Sva/9M2L1L2F+V+wwLF5LGtN7KTR67LIihxlYFLDXRMH2BRebeS47
ruW5iK6KFCvqsGGMcNF9
=mEsp
-----END PGP SIGNATURE-----

[johny...@sigaint.org]

> On 2016-08-19 05:11, johny...@sigaint.org wrote:
>> When I try to run qvm-run from within an AppVM, I get "Request refused."
>>
>> Is this by design, for security reasons? If so, I guess that's
>> perfectly
>> reasonable. I just don't see that fact documented anywhere.
>>
>
> Yes, but it's completely user-configurable. You can read all about this
> system
> here:
>
> https://www.qubes-os.org/doc/qrexec3/

Sweet!

Mainly looking to have Keepass, running in an offline AppVM, to be able to
fire up specifically-allowed URL's in a browser in another AppVM, and
stuff a password into its clipboard.

(So it sounds like I could restrict the qrexec to a custom script in the
AppVM that only opens that specific site; and stuffing the clipboard
should be pretty benign, too.)

If I'm very careful about the permissions, I should be able to keep any
risk under control. The qrexec design looks pretty flexible.

Thanks!

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Aug 19, 2016 at 08:56:38PM -0000, johny...@sigaint.org wrote:
> > On 2016-08-19 05:11, johny...@sigaint.org wrote:
> >> When I try to run qvm-run from within an AppVM, I get "Request refused."
> >>
> >> Is this by design, for security reasons? If so, I guess that's
> >> perfectly
> >> reasonable. I just don't see that fact documented anywhere.
> >>
> >
> > Yes, but it's completely user-configurable. You can read all about this
> > system
> > here:
> >
> > https://www.qubes-os.org/doc/qrexec3/
>
> Sweet!
>
> Mainly looking to have Keepass, running in an offline AppVM, to be able to
> fire up specifically-allowed URL's in a browser in another AppVM, and
> stuff a password into its clipboard.

Getting anything to/from qubes clipboard can be triggered only by an
explicit user action (ctrl-shift-c/v). This is to prevent many types of
clipboard-based attacks.

> (So it sounds like I could restrict the qrexec to a custom script in the
> AppVM that only opens that specific site; and stuffing the clipboard
> should be pretty benign, too.)

You can create new qrexec service for that (which is also described on
that linked page), but it may be tricky to do it securely.

Anyway, if you're talking about normal AppVM (not DispVM), and you want
to paste that password there from time to time, what about simply
storing that password inside the browser? It has access to this password
anyway, the only difference is when. But if it is compromised, it
doesn't matter, so you don't really get anything from not storing it
there.

This of course doesn't apply to Disposable VM (DispVM in short), which
by design should start from clean state.

> If I'm very careful about the permissions, I should be able to keep any
> risk under control. The qrexec design looks pretty flexible.
>
> Thanks!
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXxEUfAAoJENuP0xzK19csYugH/0uNjnrHicHyCvMSpS2CCPyj
c/SrAN3bnx7dOovAqzNV3Pz5cCrXEBevwwjnSermp4li9CGH1CCEq8Zx0XyGNCdB
MNjBq+mN8NzZIR3Lj0h8Hebp8rEtC5SY0oey9Rux3iM0RVjBjk6qTGse1jz5qS9K
B07vIVRAL+dX2fzvv3H8fqTUJICgVQl2H13rQbykUMm2DGvCQs3R/uldZ00V6kGn
qmLqCf3DQz1tljhkcodP0hRipWRroikdmyxre62gNddQy2e7iR0dDnF00+lzKfpl
+UakaaBfZtBE05bMWehDEWSxBALofrhcnIVQLtyZQf3akkTGToip658JLa3lvcs=
=2KFv
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-08-30 01:16, johny...@sigaint.org wrote:
> Say someone compromises the dom0 encrypted drive password, and
> then goes shuffling through the private.img file of the AppVM's to
> get at Firefox's passwords...? The VM itself wouldn't have to be
> running corrupt code for that, and keeping the passwords out of
> Firefox prevents that attack.
>
> (Firefox's master password could also help prevent such attack, I
> guess. Is strong crypto used for that? It's still a single point
> of failure, but so is the keepass master password. At least with
> keyfiles and physically taking the device with me, that keepass
> single point of failure is mitigated.)
>

Qubes is designed with the assumption that if dom0 is compromised, the
whole system is compromised. So, from a "standard" Qubes perspective,
it doesn't really make sense to talk about protecting Firefox
passwords when dom0 is assumed to be compromised. If your threat model
differs significantly from this assumption, then you may need to
specify it in more detail.

P.S. - Please keep the list CCed (unless there's a special need for
privacy, in which case, use PGP). I've noticed that you keep CCing
"qubes-users@goog" instead of "qubes...@googlegroups.com".

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXxhNMAAoJENtN07w5UDAwbXAP/2xHEtBt1X7ile4ItAQ/Ar2S
CWK8+/t7hGmif7rMMxZuUvtElJyHwotc3teYc/cQyhbyNx6eK2n8F7iEc3ib7Tb8
zOJ252EJxhaoADyBXGg4dnywFDqYW5DFjAq7pdzGtOYUpTiwNlDzpOH6bXy1stT/
sZVm3mIHh03CqgQh1zxGVfnq9H2aGF+YtsI/wS9hRbLhi+YUXfTw2PuNlfJP4d4P
ouwnJxGDDGdOq4LcbmAhHoW4yDgrXL+mhWROrbA/OHXgxWJs9pTiuhrgAFoSKKkc
ynCdHx30DK+9aJNMo65k5Oz9QulwCI3irT4v0Nlhvov5SMYzV4P8rPn8PEoxxQIw
KfeQSQcK7ftPEoM5BHkPJl5uwYKCWAhc9t+eG9dTotQB6MYxrZOIyrQt1IAxpQSm
UAQlCKjseSqauV2MKiG0jkR+2aqQFfNdEKCy57v0LePPKbepBobbNSP/ujYP2RIi
xcZav9P+799DoKbkOgYf/UZWD/fheZws3wum/n5Om7/iohP/LM9sLIWRkH/nmGAw
cK0Ku4Tg5P2IL5RNzwr4NKEeBFTXDvy3RJgmdasY0OODrp7sd/V/30qQv0PTtUTw
Jj9Z/bl49SaqrECOvzWUyoK4xmv+njzKTfXo3NejwGjxdBecj//S/d4ZDVTfkSgS
m6RtkAJYIS0Jy3TNBFRu
=daj3
-----END PGP SIGNATURE-----

[johny...@sigaint.org]

> On 2016-08-30 01:16, johny...@sigaint.org wrote:
>> Say someone compromises the dom0 encrypted drive password, and
>> then goes shuffling through the private.img file of the AppVM's to
>> get at Firefox's passwords...? The VM itself wouldn't have to be
>> running corrupt code for that, and keeping the passwords out of
>> Firefox prevents that attack.
>>
>> (Firefox's master password could also help prevent such attack, I
>> guess. Is strong crypto used for that? It's still a single point
>> of failure, but so is the keepass master password. At least with
>> keyfiles and physically taking the device with me, that keepass
>> single point of failure is mitigated.)
>>
>
> Qubes is designed with the assumption that if dom0 is compromised, the
> whole system is compromised. So, from a "standard" Qubes perspective,
> it doesn't really make sense to talk about protecting Firefox
> passwords when dom0 is assumed to be compromised. If your threat model
> differs significantly from this assumption, then you may need to
> specify it in more detail.

Understood. I think most of my security violations in the past were done
remotely, and with dom0 having no networking, that risk is quite low.
There have been occasions where I suspected physical access and a
keylogger/camera, however.

Notwithstanding "dom0 is compromised and you're screwed," there is one
threat model where Firefox passwords are less safe, possibly:

With a hardware keylogger or an over-the-shoulder-camera, one can glom the
root disk password (and any Firefox master password). Then when you're
out (or via a network card management mode, BIOS trojan, whatever) get
into the system, go through the .img files to find the Firefox passwords.
All of your online passwords are revealed at that point.

If the passwords only existed in keepass on a removable USB drive, then
they're safely with you. Even if that keylogger grabbed your keepass
password, it's no good to any attacker. And the passwords have never been
typed, so any keylogger/camera doesn't have them.

Yes, an attacker who gets into the system could at that point plant
trojans, but if you have in place other intrusion detection mechanisms
(not necessarily just on the computer) you can be aware of that fact, and
redo the system from a backup. Your computer may be toast, but your email
and online world is still safe.

I guess if you never typed your Firefox master password, but used keepass
for it, too, and assuming Firefox's password storage is strongly
encrypted, then your passwords are still pretty safe in case of a dom0
violation. Whenever you start stacking "if's" like that, though, I start
feeling less secure. :)

I do know the passwords can't be stolen if they're not on the system and
have never been typed, short of the system already having been
compromised. I don't know enough about Firefox's master password
encryption to trust it 100%. Faulty assumptions have cost me dearly in
the past, so I try to make as few as possible these days.

> P.S. - Please keep the list CCed (unless there's a special need for
> privacy, in which case, use PGP).

I definitely will share the results with the group. There's won't be
anything in the setup whose revelation would reduce my own security. :)
But I appreciate the sensitivity.

> I've noticed that you keep CCing
> "qubes-users@goog" instead of "qubes...@googlegroups.com".

Apologies. I'll be more careful cleaning up the To/Cc on mailing list
replies in the future. sigaint was truncating the field, and I neglected
to notice (until the bounce).

Hey, at least I'm not still top posting. :)

JJ