If IPv6 is configured in the VM, and it is providing network to others,
apply IPv6 firewall similar to the IPv4 one (including NAT for outgoing
traffix), instead of blocking everything. Also, enable IP forwarding for
IPv6 in such a case.
FixesQubesOS/qubes-issues#718
Start qubes-firewall (which will add "DROP by default" rule) before
enabling IP forwarding, to not leave a time slot where some connection
could go around configured firewall.
QubesOS/qubes-issues#3269
In some cases it may make sense to enfoce outgoing firewall also on
sys-net. If the service is disabled, firewall settings will be
(silently) ignored, so better be on the safe side and enable.
QubesOS/qubes-issues#3290
systemd-timesyncd.service isn't enough, for various reasons:
- it is started too early in the boot process - files in
/var/run/qubes-services are not yet there
- by default it does only one shot synchronization, and there is no
network at that early boot time yet
- by default use-ntp is set to "no"
So, in addition, enable actual ntp client.
FixesQubesOS/qubes-issues#3210
clock synchronization mechanism rewritten to use systemd-timesync instead of NtpDate; at the moment, requires:
- modifying /etc/qubes-rpc/policy/qubes.GetDate to redirect GetDate to designated clockvm
- enabling clocksync service in clockvm ( qvm-features clockvm-name service/clocksync true )
Works as specified in issue listed below, except for:
- each VM synces with clockvm after boot and every 6h
- clockvm synces time with the Internet using systemd-timesync
- dom0 synces itself with clockvm every 1h (using cron)
fixesQubesOS/qubes-issues#1230
It isn't really needed. It was used to workaround libusb bug (causing
crash when the system does not have any USB controller), but since we
use HVM now which do have some USB controllers it isn't needed anymore.
Also, it is not available in stock Fedora kernels.
Configure package manager to use 127.0.0.1:8082 as proxy instead of
"magic" IP intercepted later. The listen on this port and whenever
new connection arrives, spawn qubes.UpdatesProxy service call (to
default target domain - subject to configuration in dom0) and connect
its stdin/out to the local TCP connection. This part use systemd.socket
unit in case of systemd, and ncat --exec otherwise.
On the other end - in target domain - simply pass stdin/out to updates
proxy (tinyproxy) running locally.
It's important to _not_ configure the same VM to both be updates proxy and
use it. In practice such configuration makes little sense - if VM can
access network (which is required to run updates proxy), package manager
can use it directly. Even if this network access is through some
VPN/Tor. If a single VM would be configured as both proxy provider and
proxy user, connection would loop back to itself. Because of this, proxy
connection redirection (to qrexec service) is disabled when the same VM
also run updates proxy.
FixesQubesOS/qubes-issues#1854
...but installed on all Debian versions. This is mostly required by
vebose file list in debian/qubes-core-agent.install. But also make it
use new options when upstream will set them.
QubesOS/qubes-issues#2161
qubes-early-vm-config.service depend on qubes-db daemon running, to
retrieve various configuration parameters. But the startup ordering
declaration was missing
FixesQubesOS/qubes-issues#2750
Before, the script skipped none existing ro paths even if the path
existed below /rw. This would require someone who wants to use bind-dirs
only in TemplateBasedVM to ensure that the paths exist before the
bind-dirs script gets called.
This patch changes this behavior so that if the path exists below /rw, it
is ensured that an (empty) file/directory is present in ro (where the
corresponding path from /rw is then bind mounted over).
Requires: Docs update. I can open a PR when this PRs looks good.
Fixes limitation: "Does not work if the file / folder in question does
not already exist in the root image. I.e. a file that does not exist in
the root image cannot be bind mounted in the TemplateBasedVM."
Example use case: https://github.com/debops/ansible-persistent_paths
Tested on: Qubes OS 3.2; Debian 8 TemplateBasedVM (and Template)
Related to: https://github.com/QubesOS/qubes-issues/issues/2661
* qubesos/pr/25:
Add systemd override for haveged in xenial and stretch. (#2161) Reenable haveged.service after debian package installation
FixesQubesOS/qubes-issues#2161
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.
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.
- 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
It is needed for vchan communication. It was loaded implicitly by mount
/proc/xen, but since we're moving away from this legacy interface, load
it explicitly.
QubesOS/qubes-issues#2194
The service is really responsible for mounting /rw and /home, so should
be ordered before local-fs.target - this will allow other services
to use standard ordering targets.
This probably makes Before=qubes-gui-agent.service not needed anymore,
but do not remove it yet without extensive testing to not risk
regression.
FixesQubesOS/qubes-issues#2194
