Installing gmvault security risk

[Franz]

gmvault  is an open source application written in Python to backup and restore gmail accounts.

I am unable to install it following standard tutorials (http://gmvault.org/download.html) and get error messages that it cannot access some repositories. This should be because of the firewall rules that protect templateVMs.

In fact, if I install it into a userVM,
python setup.py install
installation works and the application also does what is supposed to do. Of course I have to reinstall it every time I close the userVM. This is not a major problem, but certainly it would be better to have it installed in template.
 

Manually downloading the files in these repositories with a userVM for further copying them to the template for installing the application seems beyond my capabilities.

So I wonder which is the best Qubes practice in this case. What I imagine is changing Firewall rules for the time necessary to install the application. Then restoring the rules. Perhaps I would need to allow ICMP traffic and DNS queries, or full network access?

But is this a serious security risk or perhaps python repositories may be considered as trust-able  as yum repositories and so this is acceptable practice?

Best

Franz

[Joanna Rutkowska]

I wouldn't say that temporarily allowing a Template VM full access to
the internet is a big risk in itself. Remember that the primary reason
for blocking internet traffic from VMs (e.g. from Template VMs) is to
prevent user mistakes (e.g. that the user do not start surfing the Web
in the Template VM).

So, if you decided (for whatever reason) to trust software XYZ (perhaps
because they have nice-looking website, or something) and want to
install it in your template (perhaps a different template than the
default system one would make sense), then it really doesn't matter that
you also allow networking for the time you're installing it. Even if you
didn't open the firewall, but if the software was malicious, your
template VM (and all VMs based on it) would still be doomed.

And even if the software is not intentionally malicious, but just buggy
in a way that it could be automatically exploited whenever the VM has
unrestricted access to the Internat (e.g. because it automatically
connects to some servers, and can easily get exploited then), then even
if you could prevent its exploitation in the template (by keeping strict
f/w rules), it would get exploited the VMs based on this template anyway.

So, it all comes down to realizing the following:

1) If you install untrusted software, the VM will get compromise,
regardless of how strict your f/w rules are.

2) Use different template (or standalone VMs) for installing untrusted
software packages.

BTW, there is more software that requires internet access to perform
installation -- the most annoying for me being Thunderbird which must be
allowed full Internet access whenever it wants to update its extensions
(which it wants to do after each TB upgrade). This is a problem for some
of my VMs that use TB, but have networking limited only e.g. to my
mailserver (in order to prevent simple mistakes such as me clicking on
an URL in a message). In that case I manually add "*/*" rules in the
firewall for this VM and *must remember* to manually remove a minute
later. Perhaps, in order to prevent a user mistake, we could add an
option "Temporarily allow full Internet access" in the Manager/Firewall
config, and qubes core would ensure to remove this extra rule on the
next VM reboot (or perhaps after some predefined timeout, such as... 5
minutes). Just in case the user forgot...

joanna.

[Marek Marczykowski-Górecki]

This can be done as manual iptables rule, which will be overridden on next
firewall update (any VM start/stop or IP change). Something like this (in
firewallvm):
sudo iptables -I FORWARD -s 10.137.1.29 -j ACCEPT

10.137.1.29 is my template VM IP, can be checked via qvm-ls -n, or in qubes
manager.
Yes, I know it isn't very user friendly, but it's working :)

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

[Brian J Smith-Sweeney]

Perhaps, in order to prevent a user mistake, we could add an

option "Temporarily allow full Internet access" in the Manager/Firewall
config, and qubes core would ensure to remove this extra rule on the
next VM reboot (or perhaps after some predefined timeout, such as... 5
minutes). Just in case the user forgot...

Fwiw I think this is an excellent idea.  

--
Cheers,
Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Smith-Sweeney , Assistant Director
ITS Technology Security Services, New York University
http://www.nyu.edu/its/security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Joanna Rutkowska]

Yeah, but the next f/w rules might not happen for many hours... I think
the timeout-based removal of the rule might much more secure.

joanna.

[Marek Marczykowski-Górecki]

This matches the idea of allowing full network access until template shutdown.
If you want predefined time, "time" iptables extension will do the work, or
even better (but more complicated) ipset with "timeout" option.

[Franz]

Many thanks for the clear explanation.

I added the last small paragraph to this page: https://qubes-os.org/trac/wiki/SoftwareUpdateVM

Best

Franz

[Axon]

Joanna Rutkowska:

I burst out laughing when I read this.

Actually, I recently tried to fix the same problem by adding the
following firewall rules in those AppVMs:

Deny network access except...

mozilla.org [any] [any]
addons.mozilla.org [any] [any]
services.addons.mozilla.org [any] [any]

This *seems* to allow TB to successfully check for updates, but I
haven't noticed whether it has successfully updated any extensions yet.
(There probably haven't been any new updates to download since I did this.)
Anyway, I wouldn't be surprised if this ends up not working, but I
figured it's worth a shot...

[Axon]

Joanna Rutkowska:

BTW, there would be an advantage to somehow disabling (or requiring
double confirmation for) all email links in TB, and that is the fact
that so many emails today are practically unreadable unless they are
allowed to load remote content (i.e., images). Of course, this is mostly
because companies and organizations just want their emails to look
fancy. But nowadays many of them don't even include a suitable plain
text version. If you have TB set to display message bodies as plain
text, either it's hopeless garbled, or it just says, "Hey, if you want
to read this message, you have to go to this mysterious
500-character-long link. Good luck!"

It would be nice if I could enable full internet access (in order to
load the remote content) in an email AppVM without worrying about
accidentally clicking on a link. With the prevalence of (spear)
phishing, I never intentionally click email links any more anyway.

[Zrubecz Laszlo]

On 5 December 2013 04:09, Axon <ax...@openmailbox.org> wrote:

> Actually, I recently tried to fix the same problem by adding the
> following firewall rules in those AppVMs:
>
> Deny network access except...
>
> mozilla.org [any] [any]
> addons.mozilla.org [any] [any]
> services.addons.mozilla.org [any] [any]

I recently set up a non caching squid proxy, mainly for URL whitelisting....
The challenge was the really weak hardware, because actually it is a
low end router running OpenWRT - thats why the non caching slim
design.

We can run the same service in a proxy/firewall VM, and we can
effectively make some nincs URL filtering - as needed.

I can publish the working squid config if interested.



--
Zrubi

[Joanna Rutkowska]

Sadly, your edits introduced lots of inaccuracies -- let me quote your
entry and discuss the problems with it below:

The original entry is here:

https://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=7&old_version=6

"
Some applications cannot be installed using the standard yum
repositories, and need to be manually downloaded and installed. These
applications are less secure. So it is recommended to install them only
in a Standalone VM.

When the installation requires internet connection to access
repositories, it will not complete because Standalone VM firewall rules
only allow connection to standard yum repositories. So it is necessary
to modify firewall rules to allow internet access. Of course, as soon as
software installation is completed, firewall rules should be returned to
the default state.
"

1) It is not true that "These [3rd party] applications are less secure"

2) Neither that: "So it is recommended to install them only in a
Standalone VM." Even if they were indeed less secure, this would not be
true, because one can very well install them into a custom template.

3) "When the installation requires internet connection to access
repositories, it will not complete because Standalone VM firewall rules
only allow connection to standard yum repositories." -- this is not
correct. The above is correct for Template VMs only, not Standalone VMs.

4) "So it is necessary to modify firewall rules to allow internet
access." No, this is only necessary if installing into a template, but
not necessary if installing into a standalone VM. In fact it would make
little sense to maintain such strict rules in a Standalone VM.

I corrected your entry to the following:
http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=history

In the future please be more careful about what you write on Qubes Wiki.

joanna.

[Joanna Rutkowska]

And I was worrying nobody gets my jokes ;)

Not a good idea IMO, even if that worked (i.e. TB could updates). I
still don't want anybody to send me email with a link going to
mozilla.org or, even worse, addons.mozilla.org and my TB to follow it
and e.g. fetch content from it and parse it. Or my clicking on it. Well,
at least not in my "work" domain. I assume anybody could place e.g. some
custom picture or other content on addons.mozilla.org...

Compared to this, I much more prefer to temporarily allow */* from time
to time (typically once a 1-2 weeks after a template update), on TB
startup only when it must update the extensions -- at least I hope the
TB verifies the digital signatures on whatever content it gets from
there and doesn't do any other HTML parsing. And then I quickly return
back to my strict rules which allow only access to SMTP/IMAP4 of my
email server.

joanna.

[Joanna Rutkowska]

Very Bad idea IMO. It is not only URL clicking we're afraid of, but
also, and especially, TB fetching and rendering some HTML content and
getting exploited then.

I solve this problem in the Classic Qubes Way:

1) My TB in my "work" domain runs in plain text only, with Internet
access to my email server only.

2) My TB in my "personal" domain (which serves also a different email
address -- my personal email address) has everything turned on. I don't
consider my "personal" domain especially sensitive, especially that it
is somehow "cloned" on my iPhone too, e.g. my iPhone has access to this
personal email account too, share PDFs between those, etc.

3*) I might also have more email addresses and domains for special
private communication, e.g. with my partner when I'm away from home.
Another set of PGP keys are used there, another email account, etc. HTML
disabled.

I consider the separation of work/person TB and email accounts a
"lifestyle" feature -- it's about a natural separation between ones
"work's life" and "personal life".

joanna.

[Axon]

Joanna Rutkowska:

My setup is actually the same as yours. When I was saying it would be
nice to load remote content, I was referring only to my "personal"
(non-sensitive) email (not "work" email or any sensitive correspondence;
each has its own AppVM). I know there are a lot of risks to fetching and
rendering HTML content in emails, but since so many of the successful
exploits seems to involve people actually clicking on links (and since I
never intentionally use a browser in that AppVM anyway), it would be
nice just to disable all the links and thereby reduce the attack surface
at no cost in functionality (for me, anyway). (Plus, TB takes a
whitelist approach to loading remote content by default.)

But, as you said, it's not terribly important, because that email
account is not sensitive and gets used on other (mobile) devices.

[Axon]

Joanna Rutkowska:

Yeah, it introduces some risk, which is why I only did this with my
non-sensitive "personal" email AppVM, just for the convenience of not
having to worry about manually changing firewall rules to allow updates.
I wouldn't try it with any important AppVMs. However, I suppose you're
right that the updates are so infrequent that the inconvenience is
pretty insignificant.