Allow to restarain DispVM networking via firewall

[marmarek]

Reported by joanna on 7 Oct 2011 14:00 UTC
Users might want to constrain their DispVMs networking abilities, so they don't leak info in case they were compromised. E.g. a user might be using a DispVM for printing (because it would be based on some less trusted template, where some 3rd party printing drivers were installed), and so might want to limit the DispVM to only doing networking in the local LAN. This allows for a reasonably safe printing by righ-clicking on a document in some very-trusted VM (which has no printing drivers installed, and might not even have networking), opening in a DispVM, and printing from there.

Migrated-From: https://wiki.qubes-os.org/ticket/370

[marmarek]

Comment by joanna on 19 Oct 2011 08:55 UTC
Ok, so the problem is that the user might also want to use DispVMs to e.g. open a website, which rises a problem of how to decided which DispVMs are allowed full networking, and which are not (e.g. my printing domain in the example above).

So, how about the following solution: the DispVM always inherits the networking filetring rules of the creating VM? (just like it currently inherits the label).

[marmarek]

Comment by joanna on 19 Oct 2011 08:55 UTC
Ok, so the problem is that the user might also want to use DispVMs to e.g. open a website, which rises a problem of how to decided which DispVMs are allowed full networking, and which are not (e.g. my printing domain in the example above).

So, how about the following solution: the DispVM always inherits the networking filetring rules of the creating VM? (just like it currently inherits the label).

[marmarek]

Comment by marmarek on 31 Oct 2011 09:50 UTC
This idea looks better. Implemented here:
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=a4e11dedd95e66023b0b2c90e4d7a804ba4287a3

Note that even when VM has no network, still can have firewall setting - which will be inherited here by DispVM (which will have network access).

If needed - firewall rules for running DispVM can be edited from qubes-manager (only when calling VM has any firewall settings).

[marmarek]

Comment by marmarek on 31 Oct 2011 09:50 UTC
This idea looks better. Implemented here:
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=a4e11dedd95e66023b0b2c90e4d7a804ba4287a3

Note that even when VM has no network, still can have firewall setting - which will be inherited here by DispVM (which will have network access).

If needed - firewall rules for running DispVM can be edited from qubes-manager (only when calling VM has any firewall settings).

[marmarek]

Comment by joanna on 31 Oct 2011 11:29 UTC
So, I think we should prevent by default the situation you described above, i.e. when a net-disconnected VM creates a DispVM, the DispVM should also be net-disconnected. This would be more conforming to the rule "DispVM inherits networking permissions of the parent VM", less confusing to users, and more safe.

[marmarek]

Comment by joanna on 31 Oct 2011 11:29 UTC
So, I think we should prevent by default the situation you described above, i.e. when a net-disconnected VM creates a DispVM, the DispVM should also be net-disconnected. This would be more conforming to the rule "DispVM inherits networking permissions of the parent VM", less confusing to users, and more safe.

[marmarek]

Comment by marmarek on 31 Oct 2011 11:34 UTC
So to print document from network-disconnected VM you will need:

1. open file in DispVM
2. connect net to this VM (currently possible only with qvm-prefs)
3. actually print

Do you think it is convenient?

If you want to have also network-isolated DispVM, you can set firewall to block all traffic from this VM (besides setting netvm to none).

[marmarek]

Comment by marmarek on 31 Oct 2011 11:34 UTC
So to print document from network-disconnected VM you will need:

1. open file in DispVM
2. connect net to this VM (currently possible only with qvm-prefs)
3. actually print

Do you think it is convenient?

If you want to have also network-isolated DispVM, you can set firewall to block all traffic from this VM (besides setting netvm to none).

[marmarek]

Comment by joanna on 31 Oct 2011 12:12 UTC
Hm... So maybe we should always apply default "deny all" firewall rules to any VM that is becoming net-disconnected. So, if a user does qvm-prefs -s appvm netvm none, then we also automatically add "deny all" rules to the appvm firewall? The question is what to do if the appvm already had some custom firewall rules?

1. Should we override those with "deny all" anyway?
2. Should we stay with the custom rules the appvm has -- I think this is undesired, as the user, after all, decided to disconected it anyway.

[marmarek]

Comment by joanna on 31 Oct 2011 12:12 UTC
Hm... So maybe we should always apply default "deny all" firewall rules to any VM that is becoming net-disconnected. So, if a user does qvm-prefs -s appvm netvm none, then we also automatically add "deny all" rules to the appvm firewall? The question is what to do if the appvm already had some custom firewall rules?

1. Should we override those with "deny all" anyway?
2. Should we stay with the custom rules the appvm has -- I think this is undesired, as the user, after all, decided to disconected it anyway.

[marmarek]

Comment by marmarek on 31 Oct 2011 12:15 UTC
The first option looks better. Perhaps we can save backup of firewall.xml.

[marmarek]

Comment by marmarek on 31 Oct 2011 12:15 UTC
The first option looks better. Perhaps we can save backup of firewall.xml.

[marmarek]

Comment by marmarek on 1 Nov 2011 14:52 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=47ad18692695112a0007f186a9a4fec04d8e72b8

[marmarek]

Comment by marmarek on 1 Nov 2011 14:52 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=47ad18692695112a0007f186a9a4fec04d8e72b8