LTS Linux kernel: good.
But what about linux-hardened? These patches target LTS Linux kernel. Good. But how stable are linux-hardened patches? Are these maintenance only for LTS kernels while newer security features / bigger changes happen for not-yet stable/LTS kernels only? In other words: does linux-hardened introduce new security features for LTS kernels?
These are exactly the thing which I am worried about here. A change by linux-hardened which makes a VM or machine unbootable due to the change.
Tested by whom and in which environments? Host only? Inside VMs? VirtualBox, KVM, Qubes? With hardened-kernel config? On Debian, which suite, buster? Inside Whonix? With apparmor-profile-everything? All of these components (virtualizer, apparmor, Debian, Whonix) add complexity and can result in non-bootable systems.
What I want to prevent here is breaking Whonix Stable Version User Experience.
I.e. a standard apt (kernel) upgrade resulting in breaking boot, connectivity, graphical desktop, apt-get or require manual fixes being applied.
I don’t think this is possible with APT.
APT can show any error messages, yes. But how can APT react? It can only either:
- leave the system in a non-broken state (i.e. can re-run APT / upgrade / install any package), which is easily overlooked and cannot be easily automated (introducing a special case) or,
- in a broken state (demanding the previous upgrade to finish, strange/hard to fix [users don’t know] error messages).
Once a package upgrade is done, there is no way to say “oh well, its actually not done, please upgrade again”.
I did not talk about gpg verification of the html with the version number yet. tb-updater has the same issue. Upstream won’t provide gpg signatures for RecommendedTBBVersions. Therefore there is an interactive Download Confirmation Notification. APT interactive is bad. To automate the build process and keep Qubes (specifically Disp)VMs updated these version numbers are hardcoded:
(With Tor Browser it is less severe since its internal updater is considered secure and reliable.)
With gpg verification is a major hassle and security risk.
I was referring this this:
curl_opts="--tlsv1.2 --proto =https --location --remote-name-all --remote-header-name"
## TODO: do not use networking as per https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598/214
curl $curl_opts "${kernel_source}" -o "${working_folder}/linux-${version}.tar.xz"
curl $curl_opts "${linux_hardened_patch}" -o "${working_folder}/linux-hardened-${version}.a.patch"
The System Security Level development goal for the Whonix software for source code and binary downloads by default is always software signatures verification security level
.
If I can maintain an up to date version file on the server, why couldn’t I also maintain a deb package in Whonix APT repository? Then no networking outside of APT needs to be invented.
The problem with the tb-updater package currently is it mixes:
- simple things such as hardcoded version numbers with
- code changes that need the usual development process (repository: developers → testers → stable-proposed-updates → stable)
Therefore hardcoded version numbers cannot be easily updated in all repositories as soon as possible. A mistake to not repeat here.
There might also be the misconception about the security that can be expected from the whonix.org server. To clear that up, this chapter was expanded just now:
Placing Trust in Whonix
I should have said superroot
.
This is always the case when there is write access. Either users are required to edit the script directly to use custom/testing versions which is harder and doesn’t stop an attacker or things are configurable through a configuration file or command line parameters. The latter is easier for users but doesn’t make an attack easier for an attacker. Since an attacker who has the skills for the attack, wouldn’t have an issue modifying the script directly either vs a config.