Allow naming hosts and add examples to rules.ml

[talex5]

Previously we passed in the interface, from which it was possible (but a little difficult) to extract the IP address and compare with some predefined ones. Now, we allow the user to list IP addresses and named
tags for them, which can be matched on easily.

Added example rules showing how to block access to an external service or allow SSH between AppVMs.

Requested at https://groups.google.com/forum/#!msg/qubes-users/BnL0nZGpJOE/csngQzaGBAAJ.

Fixes #18.

[xaki23]

oh, this is good!

i actualy have a feature/example request along these lines:
dnat rules. as in, port-forwards on the way in. for a dmz-fw.

this probably needs to go in from_netvm in rules.ml, and the basic idea of what i am using on a linux fw in that role currently is something like...
"if the dport (both tcp and udp) is between 12340 and 12349, nat to 10.137.0.34 on same port"
the 34 there in the port range and the inner dst ip are "the same", so ports 12880-12889 would go to 10.137.0.88.

i would be very happy with an example of how to write this hardcoded for each dest already.
(could probably come up with that with a lot of attempts thanks to the new examples)

bonus would be to have "take the right part of the port, check if there is a downstream vm that matches" as a "dynamic rule".
(and thats way outside of my ocaml comprehension. math! and string operations! except i am not even sure the dst is a string. or how to check if a clientvm exists.)

[talex5]

@xaki23 : we'd probably need a new DNAT action for that, although NAT_to might work as a hack. The main problem you'd have is that it currently expects you to give the target as a Packet.host, which for clients means giving it the client object, and you don't have access to that in rules.ml.

So, you'd need to add some code to firewall.ml to look up a client, perhaps based on its name in the clients list.

[talex5]

I've pushed a couple more commits on this branch:

Add some types to the rules

Before, we inferred the types from rules.ml and then the compiler checked that it was consistent with what firewall.ml expected. If it wasn't consistent then it reported the problem as being with firewall.ml, which could be confusing to users.

Give exact types for Packet.src

Before, the packet passed to rules.ml could have any host as its src. Now, from_client knows that src must be a Client, and from_netvm knows that src is External or NetVM.

More doc comments in rules.ml

[dakka2]

being able to use prefixes like 10.137.0.0/24 for source and destination would be a nice addition here as well

[talex5]

@yomimono : I've made the (commented) example rule a bit more restrictive - now only Untrusted can reply to Dev. Does that address your concerns about it?

@dakka2 : Matching whole networks sounds useful, but let's make it a separate issue.

I've also added a section to the README describing the components of the firewall, plus a diagram.