qvm-open-in-dvm fails EmailVM use case

[Axon]

Suppose that EmailVM has restrictive firewall rules allowing
communication only with the mail server (POP3S, SMTP).

User wants to open all email links in DispVMs, so User sets
qvm-open-in-dvm as the HTTP(S) handler in Thunderbird.

Now, every time User clicks on an email link in EmailVM, a fresh DispVM
is created, and Firefox running in that DispVM attempts to resolve the URL.

Problem: Since the DispVM has inherited the firewall rules of EmailVM,
the DispVM cannot resolve URLs, thereby defeating User's intention.

Thoughts? Solutions?

[Axon]

Axon:

Undesirable workarounds:

- Remove firewall rules from EmailVM. (Decreases security of EmailVM.*)
- Open all links in dedicated EmailURLVM. (Cross-contamination from
multiple different emails and/or EmailVMs. Persistency increases
likelihood of infection over time. Manually destruction/creation of
EmailURLVM is tedious and likely to be forgotten.)
- Manually start fresh DispVM from dom0, then copy URL from Email to
fresh DispVM. (Tedious, slow, lots of clicking, especially when a large
number of links need to be opened. However, safest option.)

Optimal solution(?):

- Ability to create DispVM from within EmailVM which does not inherit
firewall rules of EmailVM.



*Or does it? As has recently been repeated many times, firewall rules do
not prevent leaks. So, what are they good for? Only for preventing user
error. And what kind of user error is relevant in an EmailVM? Only
clicking on bad links, which is taken care of by qvm-open-in-dvm. So
perhaps this option is OK after all. (But then why is "restricting
EmailVM to communicating only with mail server" a Qubes selling point? ;)

[Axon]

Axon:

Ah, but there is actually another type of possible user mistake here:

The user might directly open Firefox in EmailVM, thinking that it's
WebBrowsingVM, and proceed to infect EmailVM.

[Gustav van der Merwe]

What if there were a set of templates for disposable VMs each with it's
own firewall rules as well as a EmailDispVM which inherits the EmailVM
rules. The user is presented with options to choose which VM and all but
the EmailDispVM require dom0 interaction with the user granting the
EmailVM the ability to start a DispVM with expaneded permissions.

Thoughts?

Regards,
Gustav van der Merwe

[Marek Marczykowski-Górecki]

On 30.05.2014 09:42, Axon wrote:
> Axon:
>> Suppose that EmailVM has restrictive firewall rules allowing
>> communication only with the mail server (POP3S, SMTP).
>>
>> User wants to open all email links in DispVMs, so User sets
>> qvm-open-in-dvm as the HTTP(S) handler in Thunderbird.
>>
>> Now, every time User clicks on an email link in EmailVM, a fresh DispVM
>> is created, and Firefox running in that DispVM attempts to resolve the URL.
>>
>> Problem: Since the DispVM has inherited the firewall rules of EmailVM,
>> the DispVM cannot resolve URLs, thereby defeating User's intention.
>>
>> Thoughts? Solutions?
>>
>
> Undesirable workarounds:
>
> - Remove firewall rules from EmailVM. (Decreases security of EmailVM.*)
> - Open all links in dedicated EmailURLVM. (Cross-contamination from
> multiple different emails and/or EmailVMs. Persistency increases
> likelihood of infection over time. Manually destruction/creation of
> EmailURLVM is tedious and likely to be forgotten.)
> - Manually start fresh DispVM from dom0, then copy URL from Email to
> fresh DispVM. (Tedious, slow, lots of clicking, especially when a large
> number of links need to be opened. However, safest option.)

Personally I use combination of second and third option - have DispVM (started
from dom0) running and copy&paste links there. I restart that DispVM
frequently to have reasonable clean state.

> Optimal solution(?):
>
> - Ability to create DispVM from within EmailVM which does not inherit
> firewall rules of EmailVM.
>
>
>
> *Or does it? As has recently been repeated many times, firewall rules do
> not prevent leaks. So, what are they good for? Only for preventing user
> error. And what kind of user error is relevant in an EmailVM? Only
> clicking on bad links, which is taken care of by qvm-open-in-dvm. So
> perhaps this option is OK after all. (But then why is "restricting
> EmailVM to communicating only with mail server" a Qubes selling point? ;)
>

--
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?

[Joonas Lehtonen]

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

> Problem: Since the DispVM has inherited the firewall rules of
> EmailVM, the DispVM cannot resolve URLs, thereby defeating User's
> intention.

Well it depends :) If I - the user - setup a firewall rule that allows
emailVM only connections to $mailserver, then it would be against my
intention if emailVM could reach arbitrary http server on the internet
via a dispvm.

> Undesirable workarounds:
>
> - Remove firewall rules from EmailVM. (Decreases security of
> EmailVM.*) - Open all links in dedicated EmailURLVM.
> (Cross-contamination from multiple different emails and/or
> EmailVMs. Persistency increases likelihood of infection over time.
> Manually destruction/creation of EmailURLVM is tedious and likely
> to be forgotten.) - Manually start fresh DispVM from dom0, then
> copy URL from Email to fresh DispVM. (Tedious, slow, lots of
> clicking, especially when a large number of links need to be
> opened. However, safest option.)
>
> Optimal solution(?):
>
> - Ability to create DispVM from within EmailVM which does not
> inherit firewall rules of EmailVM.

I'm surprised that no one is thinking about bug/feature #862 ;)

Not that I would advise you to do it but you could take advantage of
bug/feature #862 - (change dvm's default netvm to disable firewall
inheriting) - until it eventually gets fixed.

Qubes can't magically tell whether your EmailVM is gone rough or if
you actually clicked on a URL, so you want to set your policy to

EmailVM $dispvm ask

to confirm (in dom0) that it _probably_ was you requesting _some_ url.

By clicking on 'Yes' you are basically saying "ok I allow emailVM to
create a dispvm that is *not* bound to the firewall rules enforced in
emailVM" - as long as you *are* aware of that this should be fine.

Maybe there should be multiple buttons in the future on that
confirmation dialog, like
- - Yes, but enforce/inherit firewall rules (which actually means,
inherit netvm)
- - Yes, but don't inherit firewall rules

that would make the implications of that decision a lot more obvious.
..not that it would make that dialog less complicated ;)




-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiQbfAAoJEG58zmw5nc+vazMP/1TQ5s5rgNWWMuq/V1soN00n
AsVZs8vpV8oKPt8o7T8QCCnu1/DKnBK/oCXvZyhfE9rBa19MUoCW1uPEg+Wzf7v8
8xOImtHhXomeUiFTVQaZBNGktQKudtgHIPpalcF348Bc99UvpyE7/ZyKJ5X3kM8u
xkRV8lf8yJ7RDlkPX6k45glQACAvk/cYSaeA9AX3PIbEjo6aGjFMYbMO08bT44XI
DjFgBE3paG9320jjm6dO+KtrRRRzY3QbgJY/Vsek+XGsdziwgFOcX4rhx2p8agl6
sEEjHhAzZ2IKFZiJDYmm8moeYbSPODDeERQ76JF9t15tpf/46hpqVw/Yc0yVke6V
OfBNl+aqTrzKJL3rx8akqc+XTf7WnZrGBLQaPWmI3ZM7rTu90wtiK8nzcTVuHdWU
R+YEVTd50KekDCB2ulAvFWqlZOswDczBL9fF5EGWx5QcGk2dDMuYwiF2Yyzo3o0s
0LMx1J3ytO9z5MxC3FIvDVis5uRMWcTS0v/pgSYfPK0vG2Smczu3IoP2d8T4JYHj
3THh4r/80Qxw9JMdUDW5BwfrR3EMADTk45a2zmhkz7NGRAAR55m8RYErd8uL6sf4
6keG8LWEoOZQkF3bsDZQGbJMFUecI1AD+k1JMuvEnrRNTv07Bk0I2IxpVVDJh2KQ
D+fV/kndUy3hFHO8zqed
=kl8F
-----END PGP SIGNATURE-----

[Axon]

Joonas Lehtonen:

>> Problem: Since the DispVM has inherited the firewall rules of
>> EmailVM, the DispVM cannot resolve URLs, thereby defeating User's
>> intention.
>
> Well it depends :) If I - the user - setup a firewall rule that allows
> emailVM only connections to $mailserver, then it would be against my
> intention if emailVM could reach arbitrary http server on the internet
> via a dispvm.
>

Not necessarily. I (the user) may not want EmailVM connecting to
anything except my mail server (e.g., because I want to prevent malware
from infecting EmailVM). Nonetheless, I may want to be able to open all
links and attachments received in the emails in EmailVM. Since opening
such links and attachments in EmailVM itself greatly increases the risk
of infection, I may wish all such links and attachments to be opened in
DispVM(s).

You are assuming that the user's intention in setting up the "mail
server only" firewall rule is to prevent EmailVM from *leaking* data via
a DispVM, but this assumption is not valid in the case of an EmailVM,
since there are already other (largely unpreventable) ways for data to
be exfiltrated (e.g., covert channels, or the attacker simply emails
himself). Consequently, this appears to be one of those cases in which
we're concerned with preventing data from coming *in* but not
necessarily from going *out*.

>
>> Undesirable workarounds:
>
>> - Remove firewall rules from EmailVM. (Decreases security of
>> EmailVM.*) - Open all links in dedicated EmailURLVM.
>> (Cross-contamination from multiple different emails and/or
>> EmailVMs. Persistency increases likelihood of infection over time.
>> Manually destruction/creation of EmailURLVM is tedious and likely
>> to be forgotten.) - Manually start fresh DispVM from dom0, then
>> copy URL from Email to fresh DispVM. (Tedious, slow, lots of
>> clicking, especially when a large number of links need to be
>> opened. However, safest option.)
>
>> Optimal solution(?):
>
>> - Ability to create DispVM from within EmailVM which does not
>> inherit firewall rules of EmailVM.
>
> I'm surprised that no one is thinking about bug/feature #862 ;)
>
> Not that I would advise you to do it but you could take advantage of
> bug/feature #862 - (change dvm's default netvm to disable firewall
> inheriting) - until it eventually gets fixed.
>

That's true, but of course I would prefer a more permanent solution
which doesn't have potential negative effects on other, unrelated AppVMs.

> Qubes can't magically tell whether your EmailVM is gone rough or if
> you actually clicked on a URL, so you want to set your policy to
>
> EmailVM $dispvm ask
>
> to confirm (in dom0) that it _probably_ was you requesting _some_ url.
>

If my EmailVM has been compromised, then it's already Game Over with
respect to my EmailVM. (At this point, preventing DispVM creation won't
save me for the reasons explained above.) If my EmailVM hasn't been
compromised, then having to confirm each time I click a link is just an
unnecessary annoyance.

[Joonas Lehtonen]

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

> Not necessarily. I (the user) may not want EmailVM connecting to
> anything except my mail server (e.g., because I want to prevent
> malware from infecting EmailVM). Nonetheless, I may want to be able
> to open all links and attachments received in the emails in
> EmailVM. Since opening such links and attachments in EmailVM itself
> greatly increases the risk of infection, I may wish all such links
> and attachments to be opened in DispVM(s).
>
> You are assuming that the user's intention in setting up the "mail
> server only" firewall rule is to prevent EmailVM from *leaking*
> data via a DispVM, but this assumption is not valid in the case of
> an EmailVM, since there are already other (largely unpreventable)
> ways for data to be exfiltrated (e.g., covert channels, or the
> attacker simply emails himself). Consequently, this appears to be
> one of those cases in which we're concerned with preventing data
> from coming *in* but not necessarily from going *out*.

Everything you write here makes sense me (with one exception: firewall
safes me from malware coming to my MUA, I guess you meant the
post-exploitation).

> If my EmailVM has been compromised, then it's already Game Over
> with respect to my EmailVM. (At this point, preventing DispVM
> creation won't save me for the reasons explained above.) If my
> EmailVM hasn't been compromised, then having to confirm each time I
> click a link is just an unnecessary annoyance.

Maybe there is some value in detecting that there is something bad
going on if your EmailVM asks you for dispvm creation even though you
didn't trigger that yourself?

btw: Is there a way to detect from an AppVM if a policy is set to ask
or allow without triggering a dom0 window?

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiR+4AAoJEG58zmw5nc+vixUQALz1R3HgfOcG/sbLArMx6VNV
XuBYINK4nOt5Wf/4FH5IgaEyaGSkWKxHhKg9p+RMxf8kr/ARpQht14j+B1VT9Pvh
iZphbqxFRI6Iy44lLqMrGFAcauFZSb208hi1n9VOP8k4tNhRCBA7nV0q6I2dGAnF
toqyNJUUWmjC0hlcH209Vpjq/qtQZb39dXYIThk6g4gNR9MWi0PGmTis3ht0bXPN
O871/egO4TCsGuFIHfR5SaJizjWPXRQyaaZv6kbUdecrkUXH50L9JCEhkHJk9RSN
rrr+daznfy4Kk/WJRdsP5BDy/oFaabAnsHAEeq+RIyTMgBMY07fP3SabjeczMynR
kX4p5wY75cNULtP6sE9ODoj0l3mCCMOJvhj2smyF+8Xtjal0TvV3bmWo4SMa/skp
ubCzb719FZRH10VtRw6Ay0aq7FbEryvfqmqa5ydcmOjYh6cQC1ZUeG5iPr1MvUEv
mw4UUgBztkcjVpuJKp0CH5JWVgPIzEN3C6+Deg8mt3MkVcmrkidEig29E3Q2n8WO
tXmRL0Kz/wHRCr1jkybl3lrEYBHHov4IyPwwboWSmD9kxAj4cu528FPjqXvanhU4
8yFBqShg1LjdKlsgAL1PGBQ1SZQws9zNFqC6QxZdtEOiWFmBxNjJsI1+M7H5OimF
B11YtI8Ao51HkCJnpSN3
=Jlk+
-----END PGP SIGNATURE-----

[Axon]

Joonas Lehtonen:

>> Not necessarily. I (the user) may not want EmailVM connecting to
>> anything except my mail server (e.g., because I want to prevent
>> malware from infecting EmailVM). Nonetheless, I may want to be able
>> to open all links and attachments received in the emails in
>> EmailVM. Since opening such links and attachments in EmailVM itself
>> greatly increases the risk of infection, I may wish all such links
>> and attachments to be opened in DispVM(s).
>
>> You are assuming that the user's intention in setting up the "mail
>> server only" firewall rule is to prevent EmailVM from *leaking*
>> data via a DispVM, but this assumption is not valid in the case of
>> an EmailVM, since there are already other (largely unpreventable)
>> ways for data to be exfiltrated (e.g., covert channels, or the
>> attacker simply emails himself). Consequently, this appears to be
>> one of those cases in which we're concerned with preventing data
>> from coming *in* but not necessarily from going *out*.
>
> Everything you write here makes sense me (with one exception: firewall
> safes me from malware coming to my MUA, I guess you meant the
> post-exploitation).
>

I'm not sure what you mean. Could you explain a bit more?

>
>> If my EmailVM has been compromised, then it's already Game Over
>> with respect to my EmailVM. (At this point, preventing DispVM
>> creation won't save me for the reasons explained above.) If my
>> EmailVM hasn't been compromised, then having to confirm each time I
>> click a link is just an unnecessary annoyance.
>
> Maybe there is some value in detecting that there is something bad
> going on if your EmailVM asks you for dispvm creation even though you
> didn't trigger that yourself?
>

True, there could be value in that. I suppose one would have to weigh
that against the cost of having to confirm every time.

But there is a real risk of "confirmation fatigue" here. If, every time
I click a link, I immediately have to click a dom0 confirmation box,
then after the 100th link, what are the odds that I'm still carefully
reading the confirmation box and not just reflexively clicking "Yes" to
each confirmation box which pops up immediately after I click a link?

> btw: Is there a way to detect from an AppVM if a policy is set to ask
> or allow without triggering a dom0 window?
>

From inside the AppVM? I don't think so. But I don't know for certain.
Better to let Joanna or Marek answer.

[Marek Marczykowski-Górecki]

On 31.05.2014 03:01, Axon wrote:
> Joonas Lehtonen:

>> btw: Is there a way to detect from an AppVM if a policy is set to ask
>> or allow without triggering a dom0 window?
>>
>
> From inside the AppVM? I don't think so. But I don't know for certain.
> Better to let Joanna or Marek answer.

I'm also don't think so. But if you've called such service at least once,
source VM can guess that based on timings. So compromised VM can wait when
_you_ call the service legitimately and then try to guess used policy.

[Joonas Lehtonen]

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

>> Everything you write here makes sense me (with one exception:
>> firewall
>>> safes me from malware coming to my MUA, I guess you meant the
>>> post-exploitation).
>>>
> I'm not sure what you mean. Could you explain a bit more?

I guess I understood what you meant, now. "Firewall safes my EmailVM
from malware that would *not* attack the MUA but other client tools"
(i.e. the browser)



-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiZZCAAoJEG58zmw5nc+vfXUP/0+AJYjAlaEceaNA4F4dd+pT
pchWuuLaJAp1m7k29kZ/z8cakbwr4vMZZtWoUlHS9h9b89xE+uJ9PY5zm6iIUMxs
q72v6oDV8T0FdR7o4xE4Kg7n44L/39SCfL6xNep6TUthqUxngjdTYbszkQMZaDbP
47fNXhVZYGWG4aApeHdEA2I/rKUIvQbcjjAa0AadrDNt87WE7fABiQDtNwFakgrz
EHm3HHI/WD/xigzChH1Ofl2SP5jkt32n4t3oNGNMMNwPD9C1SdTR5TCXKnOliIMP
IhQim6atntDpy0QOxLcsId/2xC84ae2OtCs5lvAmvxmB++UryO4aUZMgXknk5M4H
7xiazQJq9BMqfOSU8kG96g5RUMxL+6N7CjXs5YlxJ73T5B5sXD9I1T4jdEPsV+ug
eB2h461f69AcTZ40U+YhCEWIQAH3SmtDglnb1plcMA6R1hxtPjBJ2fGC6hsJZdRb
RM/uA2LwfWGJSkU1glL/KkQWs4Q8Rq74PEZztM/VXdV5xc0CxyuY1BHFhBjRnvUZ
ZVsEEw4fJhUTD1WJTareh1e5yEPWvBJ+DEqyUM8WjUAsOfhlcDBUQvX632XTjgDP
zut6k5fxPCncpCxRUKE9okAtza23ChcMocpeic7q2Hd/y8uHHQyg5ND2ic9BL3V9
GQxMKROhJqbLcfMtRH5z
=625p
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

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

> I'm also don't think so. But if you've called such service at least
> once, source VM can guess that based on timings. So compromised VM
> can wait when _you_ call the service legitimately and then try to
> guess used policy.

Thanks for that info.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiZZGAAoJEG58zmw5nc+vhoAQAIPA0/nzbSEX5/USmraWJ0nb
I6yfzjxaI5NJ37TfSLPnPp0XjD+bvKnyPE3Yl572VpUFZCzdsy0tOkumnWN9GHxv
WlHY+BiD62aeX9EXHEqvy1+FuHYv9AoyMvz2Pr0QUZtjv9p9gVLuN17jDNDI9FCj
KnjIo2k+NKVo+Bp0B5QUGw7Fnwb7pb7W/MAVk7bUc808r6Cj9BIHvselmnjM703X
TwTknxOFjlJdUuc46RF+5XjWQ1AUhIgdeGQtrcoys2kZIcyTURvFRA06L4SCUI/r
TnfNeHxB8j7RoP7uyPZT3NUW1OGKrdYnNgW0e+ElsRFzblZC4xB2hquFVbbKyijp
hPIomml5FKfvwNbgT70mdfWwT1XoFol2uhL5DMjfB3lKjKMjf7ZkwkIMX+RbmuNb
4OV8YgCkuNel37EkYgnK+mhMTU8EpM+ydVyO8nkefBpSpvZXbvdqoss+eYIhaPc/
t3c7mE2DeKo1feTpVhGf8l4nhiRX7/ivkekZH4HzL0TCrWC8WiR4Xhb1go5bQPSD
8SU9YgG7AzJmByKkK3jqN/dpN2d9Of+a7+NcgxHh5qlxlHWCW14QfMFXtrEKp2gn
H36YtHyrhzYnOEUlOdpYMzu9EWkhWF3Tigreo2kpUT/WU1C8LQmWgOnjknqREtJe
kzit2iFmzgTTGhuHyTEU
=guSk
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

Moving to qubes-devel, please respond there.

On 05/31/14 01:56, Axon wrote:
> Joonas Lehtonen:
>>> >> Problem: Since the DispVM has inherited the firewall rules of
>>> >> EmailVM, the DispVM cannot resolve URLs, thereby defeating User's
>>> >> intention.
>> >
>> > Well it depends :) If I - the user - setup a firewall rule that allows
>> > emailVM only connections to $mailserver, then it would be against my
>> > intention if emailVM could reach arbitrary http server on the internet
>> > via a dispvm.
>> >
> Not necessarily. I (the user) may not want EmailVM connecting to
> anything except my mail server (e.g., because I want to prevent malware
> from infecting EmailVM). Nonetheless, I may want to be able to open all
> links and attachments received in the emails in EmailVM. Since opening
> such links and attachments in EmailVM itself greatly increases the risk
> of infection, I may wish all such links and attachments to be opened in
> DispVM(s).

/.../

Etc, etc.

I think we will all agree that "one DispVM is not enough for everybody"
and that we really need more flexibility...

If we think about why people might want to create a DispVM there are two
primary reasons I think:

1) Because it always comes up clean (no persistent home dir, more
technically no /rw mounted).

2) Because it starts up quickly (which is possible because the VM is
restored from the previously saved "savefile" which is kept in /dev/shm,
which means we don't need to boot a Linux OS, but only restore it from
"suspend", kind of).

There is no reason why we should not be able to support #1 for regular
AppVMs, I think (in that case their "regularity" would mean: VMs which
user can configure by choosing their template, netvm, firewall, etc).
This could be settable via qvm-prefs, so that we could do e.g.:

qvm-prefs anonvm -s disposable true
qvm-prefs anonvm -s netvm torvm

Some other "DispVM" could be prepared for as a convenient document viewer:

qvm-prefs docviewer -s template fedora-20-office
qvm-prefs docviewer -s disposable true
qvm-prefs docviewer -s netvm none

So, whenever Qubes is to start an AppVM which has "disposable" property
set, it will: 1) not mount the /rw for it, and 2) give it a name:
${basename}-{$uid}

We still might have a default dispvm in the system, of course -- this
would be based on the default template and using default netvm and
default f/w settings.

The policies could then be defined like this:

work docviewer allow
anonvm $anyvm deny

The reason #2 given above (quick start from savefile) is somehow
orthogonal to the property discussed in #1 -- I think we can use it even
for normal AppVMs, just make sure we generate the savefile without /rw
and then mount it after the VM wakes up after restore.

In some other scenarios, we might not want to, or not be able to, use
savefile restoration even for the VMs with "disposable" flag (e.g.
Windows AppVMs).

The above change should allow for more flexible and powerful
configurations, satisfying various users who often have varying
expectations as witnessed in the original thread.

I wouldn't even be entirely against introduction of the "disposable"
flag before R2, if that is really so simple as I think :) Marek, what's
your take on this?

joanna.