Many of the Pi-Hole releases of this year were made due to security
vulnerabilities. None of them are to concern to Qusal users.
- GHSA-jg6g-rrj6-xfg6: Requires authenticated user;
- GHSA-95g6-7q26-mp9x: Requires authenticated user; and
- GHSA-3597-244c-wrpj: Requires shell in the same qube running Pi-Hole.
The admin interface is only allowed through localhost, therefore only
sys-pihole and sys-pihole-browser qubes have access to it, blocked by
firewall (nftables) and HTTP server (lighttpd). Qubes with access to the
admin interface are not of a concern, we assume that every qube that has
access to the admin interface is trusted, therefore, only if a qube
doesn't have access to the admin interface and can gain access, it
becomes a concern, which hasn't happened.
Ideally, it would be a Qrexec socket service, but it doesn't handle DNS,
only accepting IPs. The dev qube is now non-networked and network,
especially to remote git repositories can be acquired via the proxy that
is going to be installed in every netvm.
Ability to read the program's manual from the terminal is much better
than to ask the user to search the manual page on the internet, we
already trust the installed program and documentation, but we should not
trust every manual page on the internet.
Updates happens multiple times, normally 2 to 3, even if we consider a
state without includes. On states with multiple includes, it could
easily get approximately 10 updates being ran. This behavior leads to
unnecessary network bandwidth being spent and more time to run the
installation state. When the connection is slow and not using the
cacher, such as torified connections on Whonix, the installation can
occurs much faster.
Adding external repositories has to be done prior to update to ensure it
is also fetched.
Fixes: https://github.com/ben-grande/qusal/issues/29
Git revision is specified in the git module to Salt not fail trying to
verify it is in HEAD when it is in a tag from a previous installation.
Fixes: https://github.com/ben-grande/qusal/issues/27
- Passwordless as it doesn't compromise security;
- Firewall blocks access to the interface in case the pihole is exposed
to the internet;
- setupVars.conf needs to be 644 for non root commands to the pihole
script to work, so the WEB_PASSWORD can be read as normal user,
restricting root on pihole does not make sense, as it can modify the
network setting via pihole web interface.
