Suggestion: Allow modification of Firewall Rules of several Vms at once

[grzegorz....@gmail.com]

Preamble
Qubes OS offers an option to restrict network traffic within a VM to a specific address/domain/website which is a very useful feature as it allows the user to control networking within VMs.

Issue
However if the user wants to be 100% sure only the dedicated VM can access a specific web resource, they need not only to allow the dedicated VM access to a said resource, they also need to deny access to said resource for every other VM they use. As the number of VMs grow larger this task will get more and more mundane.

Suggestion
Allow users to apply firewall rules to several VMs at once. This mechanism could be implemented either in Qubes Manager GUI or as a separate GUI application.

Sample options

Make exclusive - allowing access to a specific resource automatically denies access to said resource for all other VMs except for the system VMs

Apply to all - allowing access to a specific resource grants all other VMs access to said resource

Apply to selected - additional checkbox would appear in QM allowing the user to select VMs to which the rule would apply

Apply to all from the same TemplateVM - self-explanatory

I believe such a feature would greatly improve the efficiency as well as minimize the risk of user error.

[Andrew David Wong]

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

On 2016-06-30 14:15, grzegorz....@gmail.com wrote:
>
> Preamble Qubes OS offers an option to restrict network traffic
> within a VM to a specific address/domain/website which is a very
> useful feature as it allows the user to control networking within
> VMs.
>
>
> Issue However if the user wants to be 100% sure only the dedicated
> VM can access a specific web resource, they need not only to allow
> the dedicated VM access to a said resource, they also need to deny
> access to said resource for every other VM they use. As the number
> of VMs grow larger this task will get more and more mundane.
>

Just out of curiosity, would you mind offering an example of a concrete
use case?

> Suggestion Allow users to apply firewall rules to several VMs at
> once. This mechanism could be implemented either in Qubes Manager
> GUI or as a separate GUI application.
>
> Sample options
>
> Make exclusive - allowing access to a specific resource
> automatically denies access to said resource for all other VMs
> except for the system VMs
>
> Apply to all - allowing access to a specific resource grants all
> other VMs access to said resource
>
> Apply to selected - additional checkbox would appear in QM allowing
> the user to select VMs to which the rule would apply
>
> Apply to all from the same TemplateVM - self-explanatory
>
> I believe such a feature would greatly improve the efficiency as
> well as minimize the risk of user error.
>

Thanks for the suggestion. Tracking it here:

https://github.com/QubesOS/qubes-issues/issues/2139

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

iQIcBAEBCgAGBQJXdf3MAAoJENtN07w5UDAwOFkP/2uWAsdLEvILk0C3jK4QRejI
KeX7W3s5HXNylwnzkh5KArEF3Khb2MWrHdpXoYmWcCn+86S94twjztv0QnkDpEC9
J94Hfi5QYy3CgDJSjDOGcdHfvpR59nagAhLeAXOdjzM5jO50Y2ct+Wpc2zX8jwRv
/ihC6a7+dthnvA6mjNu48bkfYV6DyKGhohlTwqMixzFTBjAfBLRd2+b1z3j6tpts
FOygXTPyF0G8Wpx3wLhQAuog1Ij5HE8yBEj1x5I47naNPA4t7Swr6kMptlzzdcN2
uD4lTqFxA1lGXnLdjMOExaxNUkhDISLvNybQiRxFfmRu0R7MOq/S3RRa2bmHwfYB
XIeYeIlWYh0kA9IvUHl/hF/fvoTrFXAguTFDw9lZYc0+Jq1yPWcojw0SdPkbVSuQ
DjHod/cLTOeqlmYuWWA4WgYtPThsxEEbp6bPcunku++OQkemz+F39nboj2WANVVU
GczGe13obGhFKa4++ujKZvnxdKxKBF6pE2VYSrv/+5MIfIhUYMvj/seHXoG3POjV
Kj9A9IWuc31erGrF4QyjZzETyRWmWUm2ElqwqidfemZzxXG4BwryHAWtcApR26/i
pnHpn3rvxUGt/a/E2Vt7Htm6ckbhtOMisBc0gT3WkSYPvFufqjWdbdcHU46FvXnb
ce2eIvJv+/E78QpStSag
=fO8g
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Thanks for suggestion. But in practice we don't have resources to
implement this (we have a lot of higher priority tasks). So either
someone from the community would implement this, or no one....

That's said, it is already possible using command line interface and a
simple script. For example:

for vm in work-vm1 work-vm2 work-vm3; do
qvm-firewall -a $vm corporate-server.com tcp https
done

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

iQEcBAEBCAAGBQJXdhgGAAoJENuP0xzK19csISgH/0J0XKwKe11Phn1Z1ZwuMuAR
t2wOj/Icc8g4hIgypYMPuEMiivjArw6scCEoLRTIqDVFlO01tGwkdTomb/Nkah87
n/dI37/dVn83KOz4k58Oo3El/EDJxZYk3EiRb7eZa0XhZ03GzskYVkDXuqjdAqDB
jAjKVWD8XqMOmfv67ZoFmkvFaJjZF56/JcGHCdiFMl3bwy+ForO78VG8Qo+lChmG
0Qmp9sK0hcx6QZzBhfeu+1ZCvANqXPzD7v/sPTNgie9Ivd14pMVvHSOwItYsJNng
ufwPepGdPcO1hp2YAu1TPYPekbtAyZuHI2irDpxJFSPVHqv5SxXnj8yg9fqzJr4=
=b4EL
-----END PGP SIGNATURE-----

[Drew White]

Perhaps this is something that can be added in when the manager is fixed and the issues with the memory leak and functionality and many other bugs are resolved?

This would be a good addition. As it is something that I believe many people would benefit from.

[Grzesiek Chodzicki]

@Andrew

A user has a network share on the internal network. This share does not require the user to provide any extra credentials to access it (for the same reason Qubes uses passwordless sudo).

The user creates a separate AppVM in order to access the share and, in Qubes Firewall, allows the AppVM to connect to the share.
However unless the user specifically forbids every other VM access to the share they can connect to it too (due to Qubes NAT all AppVMs use the same LAN IP and MAC address so the share cannot differentiate between the AppVM that is supposed to access it and AppVMs that aren't).

Because every AppVM can connect to the share they can now use it as a covert communications channel.

I tried to be as clear as I could with this one I hope You understand what I'm trying to convey.

@Marek

Thanks for the tip! I did not know that. However I think it would be really helpful if the same task could be carried out within the GUI and with more granular control over VMs.

[Andrew David Wong]

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

On 2016-07-01 11:04, Grzesiek Chodzicki wrote:
> @Andrew
>
> A user has a network share on the internal network. This share
> does not require the user to provide any extra credentials to
> access it (for the same reason Qubes uses passwordless sudo). The
> user creates a separate AppVM in order to access the share and, in
> Qubes Firewall, allows the AppVM to connect to the share. However
> unless the user specifically forbids every other VM access to the
> share they can connect to it too (due to Qubes NAT all AppVMs use
> the same LAN IP and MAC address so the share cannot differentiate
> between the AppVM that is supposed to access it and AppVMs that
> aren't). Because every AppVM can connect to the share they can now
> use it as a covert communications channel.
>
> I tried to be as clear as I could with this one I hope You
> understand what I'm trying to convey.
>

Why not require a password to access the network share, then only
type/paste that password in the authorized AppVM? The reason for
passwordless sudo in Qubes is that it provides no extra security, but
it seems like requiring a password to access your network share would
provide some security in this situation (unless, of course, the
authentication mechanism can be trivially bypassed for some reason).

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

iQIcBAEBCgAGBQJXdyIUAAoJENtN07w5UDAw2PYP/iWzPLc1qJGeJt4IEPeS/wGt
/B8H/BOh8Q/sxIycLMgVUx0rVRr3TgjgFMgMG0YH8NqyUTFaUrVACfrCNDRhEQmC
apma7ypOdFB5ztoKIgZhs0p65hktATOwF/2ivrupuVgQISKMDXa5hwegX2+jxTnh
rty6gpO1GDK1JAWiyTxI8tcV1xeeDEz6vA9LKJmDHWDXewxvQ5iOcbF7fyBhm3wb
dCvfVJkEg7CELfkpDyTNYIqjvSq0X7A+RuACP4wa+bZNx8tr5ipBrrPf9/gWjgsI
xHslUd6Vg4M0y5/AwvC4XMwA6RRb7Gk+3i/L27dm+NbrGMT5pG6Spx7ftrnCDyMr
3HQb46B8JDrrU+6OKxibvOotJ1Th/gYdnA4WAxZe/bDgji7rpJF8ANxsvM8d6zFA
JQtfn1VhukJYFhhIBqHy5eaKEvoyUrb7nnifgt1//5HeEd+m3IBeM+6Vc7l2VgJi
62ttY35Nc2q+XGTDSZPpCH5SbpXAl1UKZEwpu7c1GnmRBq9n2G4U3+fhNDXMBmSO
pGWaHrsziVBDlpfKq5xqUljRydSQvg9dHUcDFgIx+Q2EKe51m0D1q3+nlbylLOfu
Jge/7xDlF9OO+ioo7QjkmVrSbOS0BSRbk3i/+fF3OePnW5tE20/d6gqdOz2qNFdP
Y3gTKwSdNF1gbzPLAMZl
=2/gF
-----END PGP SIGNATURE-----

[Grzesiek Chodzicki]

The users who are connected to the network are assumed to be authorized. The firewall restriction is not meant to protect the share against malicious users, it is supposed to protect against untrusted AppVMs.
Moreover password based authentication could be used by malicious AppVMs in a Denial-Of-Service scenario where AppVMs send authentication requests to exhaust server resources.

[Andrew David Wong]

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

On 2016-07-02 02:50, Grzesiek Chodzicki wrote:
> The users who are connected to the network are assumed to be
> authorized. The firewall restriction is not meant to protect the
> share against malicious users, it is supposed to protect against
> untrusted AppVMs.

What's the difference between a malicious user and a malicious AppVM?

> Moreover password based authentication could be used by malicious
> AppVMs in a Denial-Of-Service scenario where AppVMs send
> authentication requests to exhaust server resources.
>

Ok, but isn't it the server's responsibility to protect itself from
that sort of attack? What if you have other, non-Qubes machines on
your network, and one or more of them gets compromised and tries to
DoS the server?

Certainly if we're talking about a home network using a consumer
router, the network should be regarded as untrusted. (Even more so if
the network is shared with anyone else.)


P.S. - Please avoid top posting.

iQIcBAEBCgAGBQJXd8U9AAoJENtN07w5UDAwx2YP/2UgTlkKtoWUYrPGfHKQssDa
S1Ml5NuwSL7vM+YuavJA/vlk9JZGq6A0JtNXtq4hkavwbZbezkwGmnC4TqeV5tUv
PF6HHUXRmuUvukbLy6drlPBJEzjylNCfNfL6ef54zJwWgCiX4Y0G5TOJIqN2ANGt
sFNQ5wN9qn9JxO9iTCOXBTinxA+aAP9uxUzFaMxxGq47aUwwFTJmra1JvCj7XtF2
2DZmk9P+NyYTRADIVITXGuStEvA7CdCIli6rECe4ObRwOUpWb0yI/4bgUMvGeNm9
ZnhaX3+V4mWVT3dYc/5SLgEXwGdMrU+a9tEeAv1DDGlTT1o3arolTmUh+C6oCxFi
vgqsqjjIMqYDhw9snFZTn3ggS9D9/DnwW42bV2BNTxsQujnJMIAoKqz0QueBb8fz
unMoGwe0bfL4DotVVHcGai3rMQeuFdvhCnUcOhIxtyiZpat/u0OCpCOiZFOAMdVn
ngX2hQbDjvfjjNKzoTnB7A4yUEJMp2Dh6MQjLw2ybCbH/zqQEL8OeeKZ9QtBkCvu
5FZX1/wREGP+S+LKcTFFr1su0kOvG3i+GM8fxLM3CUUJjfTNf8dFoNPE10bxdUtr
mSUSW4+UN2adEn88wH9wdP4mNN6G16TVKgT4ra/4ZobeJViMgZiee+ahTgjbq8ri
YQiuDsOoOdCumQ+UqpsU
=5+uP
-----END PGP SIGNATURE-----

[grzegorz....@gmail.com]

Sorry about top-posting I clicked on reply-to-all.

>What's the difference between a malicious user and a malicious AppVM?

Even if AppVM becomes malicious, its network access is restricted by the Qubes firewall (unless the AppVM can somehow escape the sandbox but that's beside the scope of the discussion). A malicious user would have unrestricted control over his/her system.

>Ok, but isn't it the server's responsibility to protect itself from
>that sort of attack? What if you have other, non-Qubes machines on
>your network, and one or more of them gets compromised and tries to
>DoS the server?

>Certainly if we're talking about a home network using a consumer
>router, the network should be regarded as untrusted. (Even more so if
>the network is shared with anyone else.)

It most certainly is the server's responsibility but it wouldn't hurt if the attack surface was reduced by restricting VMs access to it.

I understand that this is a very low priority issue however I feel that it would help users easily enforce the least-access policy in their Qubes instances.