Use /32 inside network namespace too. Otherwise inter-VM traffic is
broken - as all VMs seems to be in a single /24 subnet, but in fact are
not.
QubesOS/qubes-issues#1143
Core3 no longer reuse netvm own IP for primary DNS. At the same time,
disable dropping traffic to netvm itself because it breaks DNS (as one
of blocked things). This allows VM to learn real netvm IP, but:
- this mechanism is not intended to avoid detection from already
compromised VM, only about unintentional leaks
- this can be prevented using vif-qubes-nat.sh on the netvm itself (so
it will also have hidden its own IP)
QubesOS/qubes-issues#1143
Since 'script' xenstore entry no longer allows passing arguments
(actually this always was a side effect, not intended behaviour), we
need to pass additional parameters some other way. Natural choice for
Qubes-specific script is to use QubesDB.
And since those parameters are passed some other way, it is no longer
necessary to keep it as separate script.
FixesQubesOS/qubes-issues#1143
Keep "main" IP (the one in xenstore) as the one seen by the netvm, and
pass the "fake" one (the one seen by the VM) as script parameter.
FixesQubesOS/qubes-issues#1143
Up until today, Qubes OS would insist on either masking or disabling
or activating units that should get their state properly changed
but only on first package install (when the template is built).
This commit adds the possibility of having two types of unit presets:
* Initial presets: these are only changed state during first package
installs.
* Upgrade presets: these get their state changed during first
package installs as well as during upgrades.
All the maintainer has to do is abide by the instructions in the
preset file. Nothing else is necessary.
Namely, this allows users to enable SSHD on their templates or
standalone VMs and still keep it enabled even after the
qubes-core-vm-systemd package is upgraded.
Matt really wanted that, and so did I, so now we can do it!
:-)
qubes-setup-dnat-to-ns is called multiple times during boot. Of particular interest are the two invocations done by:
1. `/usr/lib/qubes/init/network-proxy.setup.sh` (`qubes-network.service`)
2. `/usr/lib/qubes/init/misc-post.sh` (`qubes-misc-post.service`)
These can, and do often, run in parallel. Often enough that the `PR-QBS` `nat` chain can end up with eight rules instead of four, or (worse) zero rules.
This commit represents the proper boot ordering of these services, where the post startup *must* happen after Qubes has already started its iptables, firewall, network setup and netwatcher.
This eliminates the race.
Do not use a symlink there, as it will be left after NetworkManager
shutdown - as a broken link then
FixesQubesOS/qubes-issues#2320
Reported by Achim Patzner <noses@noses.com>
This rewrite is mainly to adopt new interface for Qubes 4.x.
Main changes:
- change language from bash to python, introduce qubesagent python package
- support both nftables (preferred) and iptables
- new interface (https://qubes-os.org/doc/vm-interface/)
- IPv6 support
- unit tests included
- nftables version support running along with other firewall loaded
FixesQubesOS/qubes-issues#1815QubesOS/qubes-issues#718
f4d367a6 dropped the check if the bind target exists and added
"--no-clobber" to the cp call. For directories this does not work as
desired: cp checks per (recursive) file instead of once for the
specified directory.
The systemctl in Debian unstable fails when trying to disable a removed
service. The manpage do not mention a switch to change this behaviour.
But it says:
Note that this operation creates only the suggested symlinks for
the units. While this command is the recommended way to manipulate
the unit configuration directory, the administrator is free to make
additional changes manually by placing or removing symlinks in the
directory.
So a simple rm should be fine.
- qubes-misc-post.service is no longer responsible for mounting /rw
- both qubes-sysinit.service and qubes-mount-dirs.service are part of
basic.target, so no need to mention them explicitly (as long as
DefaultDependencies=yes)
QubesOS/qubes-issues#2198
