* origin/pr/303:
firewall: prefer - over _ for QubesDB path
firewall: put DNS resolving into its own function
firewall: start watches before initial load
tests/firewall: added test for /dns/[ip]/[domain] info
tests/firewall: some code refactoring
add some checks for QubesDB /qubes-firewall_handled/[ip]
firewall: adjust tests to the new tuple returned by prepare_rules()
firewall: mark an IP as handled in /qubes-firewall_handled/[ip] after each handling iteration
mock qubesdb.rm()
firewall: refactor to remove side effects from prepare_rules()
Export DNS information obtained during firewall setup to QubesDB
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.
Prevents:
Traceback (most recent call last):
File "/usr/bin/qvm-features-request", line 81, in <module>
sys.exit(main())
File "/usr/bin/qvm-features-request", line 78, in main
stdin=devnull, stdout=devnull)
File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['qrexec-client-vm', 'dom0', 'qubes.FeaturesRequest']' returned non-zero exit status 127.
and
Traceback (most recent call last):
File "/usr/bin/qvm-features-request", line 81, in <module>
sys.exit(main())
File "/usr/bin/qvm-features-request", line 70, in main
qdb = qubesdb.QubesDB()
qubesdb.Error: (2, 'No such file or directory')
FixesQubesOS/qubes-issues#4469
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.
