This should avoid a race condition where we miss an update to QubesDB
that happens right after the initial load, but before the watch start.
Instead, we might now install the same stuff twice - but that's no
problem.
each handling iteration
Actually a counter is increased after each handling iteration.
This is useful for user applications to remain up to date with the
changes implemented by the Qubes firewall.
This can e.g. allow DNS applications to pin a FQDN to the IP
used during Qubes OS firewall setup.
Can help with QubesOS/qubes-issues#5225 and other related issues.
We do have NetworkManager new enough to handle this feature already.
Enable both scan MAC address randomization, and also connection mac
address randomization. The later do in a "stable" way - preserving the
same MAC _for a connection_, until reboot. This is a safe tradeoff
between full random, which breaks some captive portals. The stable MAC
is generated separate for each connection, so it also prevents
correlation of the same machine between different networks.
Do not enable it for wired connections, as those are less often used at
random untrusted localizations, but also more often it's desired to
get the same IP address each time (having random MAC would make it much
harder).
QubesOS/qubes-issues#938
Red Hat- and Debian- derived distributions support SELinux, and so their
sudo packages are built with SELinux support. However, other
distributions (notably Arch) build sudo without SELinux. Such sudo
builds will fail to parse the `ROLE=unconfined_r TYPE=unconfined_t`
string added in 0fac1aa45c. They *can*
parse `role=unconfined_r, type=unconfined_t` in `Defaults`, but that
causes problems on some Fedora 33 systems if SELinux is turned off and
the root account is locked.
To solve both of these problems at once, we install a different
`/etc/sudoers.d/qubes` file depending on the distribution. As a
heuristic, we use the presents of `/etc/redhat-release` or
`/etc/debian_version`. If either is present, sudo probably supports
SELinux, and we should include the corresponding entries. If both are
missing, then we shouldn’t risk it. The `qubes.sudoers` file in the git
repository includes the full file (with SELinux); we use `sed` to strip
the SELinux portion when needed.
qubes-core-agent-networking package brings in new systemd units, which
needs to be enabled. Standard %systemd_post macro handles it only on
initial installation, but not on update. The function that handle
updates is in %post of qubes-core-agent-systemd package. To avoid
duplication, simply enforce proper installation order, instead of
modifying %post of qubes-core-agent-networking package.
OrderWithRequires influences only ordering, but does not introduce
actual dependency, so it's still possible to not install
qubes-core-agent-networking package.
Fixes 0e0c229 "rpm: enable qubes-network-uplink.service on install"
By settinf Defaults role/type parameters, sudo starts asking for
password when called as root. It isn't clear why this happens, but
rollback that change. Instead, set ROLE/TYPE just for the rule for the
'qubes' group, which already has NOPASSWD option.
Fixes 3bcc1c3 "“sudo” must remove SELinux restrictions"
The setup-ip script requires extra parameters (action and interface) not
only env variables. Since NetworkManager service is already ordered
after qubes-network-uplink.service, the setup-ip already did its job at
this time - remove the call instead of fixing it.
* origin/pr/267:
fix for ArchLinux: notify dom0 about installed updates The launch of the qubes-update-check service failed on ArchLinux, because the qubes-rpc uses the `service` command which isn't available for this OS.
fix archlinux detection of available upgrades note: checkupdates return 2 when no updates are available (source: man page and source code)
upgrades-installed-check requires pacman-contrib for checkupdates
