* origin/pr/232:
Use netvm_gw_ip instead of netvm_ip
Remove commented-out code
Add NetVM-facing neighbor entry in NAT namespace
Optimization: use `ip -n` over `ip netns exec`
NAT network namespaces need neighbor entries
vif-route-qubes: better input validation
Don’t use onlink flag for nexthop
Fix running under -euo pipefail
Don’t hardcode MAC addresses
Add gateway IP+MAC, not VM’s own
Add permanent neighbor entries
network: prevent IP spoofing on upstream (eth0) interface
network: setup anti-spoofing firewall rules before enabling the interface
The socket path will be included in a shell command and then as a socat
argument, so only allow a small subset of known-safe characters. In
practice, this has not been a problem because mktemp doesn’t include
these characters in its output.
Since AppVMs will have their own NetVM-facing neighbor entries, a user
might (correctly) conclude that NetVMs do not need ARP or NDP enabled.
For this to work with NAT namespaces, they need their own neighbor
entries.
Currently there is just one anti-spoofing firewall rule ensuring packets
coming through vif+ interfaces have the right source address. Add
another rule ensuring that addresses that belongs to VMs behind those
vif+ interface do not appear on other interfaces (specifically eth0, but
also physical ones).
Normally it wouldn't be an issue because of rp_filter (doing the same
based on route table), default DROP in FORWARD chain and also conntrack
(the need to guess exact port numbers and sequence numbers). But it
appears all three mechanisms are ineffective in some cases:
- rp_filter in many distributions (including Fedora and Debian) was
switched to Loose Mode, which doesn't verify exact interface
- there is a rule in FORWARD table allowing established connections and
conntrack does not keep track of input/output interfaces
- CVE-2019-14899 allows to guess all the data needed to inject packets
Reported-by: Demi M. Obenour <demiobenour@gmail.com>
Previously enabling the interface was the first action in the setup
steps. Linux theoretically do not forward the traffic until proper
IP address and route is added to the interface (depending on rp_filter
setting). But instead of relying on this opaque behavior better setup
anti-spoofing rules earlier. Also, add 'set -o pipefail' for more
reliable error handling.
Note the rules for actual VM traffic (qvm-firewall) are properly
enforced - until those rules are loaded, traffic from appropriate vif
interface is blocked. But this relies on proper source IP address,
anti-spoofing rules need to be setup race-free.
Reported-by: Demi M. Obenour <demiobenour@gmail.com>
Check just 10 MiB of the private volume + blkid before considering it
empty and calling mkfs. Avoid reading 1GB of data at the VM boot -
which should speed up startup even further, especially for fresh
DispVMs.
QubesOS/qubes-issues#3758
fsck may require significant amount of RAM, enable swap earlier to avoid
out of memory condition. Implement this as a separate service unit, not
a swap unit, because the latter requires udev running (implicit
dependency on dev-xvdc1.device) which is not the case before remounting
root filesystem read-write.
QubesOS/qubes-issues#6174
Grub scripts are very persistent in trying to use what is currently
mounted as /. Even if currently (TemplateVM) /dev/xvda3 is mounted
directly, all the configuration should use /dev/mapper/dmroot, to work
also in AppVM.
GRUB_DEVICE is used in various places as root device (including
constructing root= parameter in some versions). Force it to
/dev/mapper/dmroot
QubesOS/qubes-issues#6174
Resolves issue where the dom0 rpm database does not get used on
successive calls to qubes-dom0-update for debian updatevms.
Also resolves "cannot remove .rpmdbold.####" occurrences.
qubesos/qubes-issues#6124
