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.

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.

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.

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.