In the (commented-out) example rules, instead of allowing any client to
continue a TCP flow with any other client, just allow Untrusted to reply
to Dev. This is all that is needed to make the SSH example work.
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`.
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 it reported the problem as being with firewall.ml, which could be
confusing to users.
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/d/msg/qubes-users/BnL0nZGpJOE/61HOBg1rCgAJ.
Xen appears to configure the same MAC address for both the frontend
and backend in XenStore. e.g.
[tal@dom0 ~]$ xenstore-ls /local/domain/3/backend/vif/19/0
frontend = "/local/domain/19/device/vif/0"
mac = "00:16:3e:5e:6c:00"
[...]
[tal@dom0 ~]$ xenstore-ls /local/domain/19/device/vif/0
mac = "00:16:3e:5e:6c:00"
This works if the client uses just a simple ethernet device, but fails
if it connects via a bridge. HVM domains have an associated stub domain
running qemu, which provides an emulated network device. The stub domain
uses a bridge to connect qemu's interface with eth0, and this didn't
work.
Force the use of the fixed version of mirage-net-xen, which no longer
uses XenStore to get the backend MAC, and provides a new function to get
the frontend one.
All files are now added using the date the build-with-docker script was
last changed. Since this includes the hash of the result, it should be
up-to-date. This ensures that rebuilding the archive doesn't change it
in any way.
Reported-by: Holger Levsen
If the firewall is restarted while AppVMs are connected, qubesd tries to
reconnect them before starting the GUI agent. However, the firewall was
waiting for the GUI agent to connect before handling the connections.
This led to a 10s delay on restart for each client VM.
Reported by xaki23.
Had stopped working:
Err http://security.debian.org/ jessie/updates/main libxenstore3.0 amd64 4.4.1-9+deb8u10
404 Not Found [IP: 128.61.240.73 80]
Updated from Debian 8 to Debian 9, and from opam to opam2.
