Yes, Clang can be considered. Though, I wouldn’t know how to make the
change and also the packaging is an issue still even with gcc.
LATENT_ENTROPY isn’t that important so the only big losses would be RANDSTRUCT and STACKLEAK.
OK. I guess doesn’t hurt to keep the kernel command line in case it gets
added at some point in future.
madaidan via Whonix Forum:
No. I’m not saying to check
/proc/cmdlinein security-misc. This would setslub_debug=FZandpage_poison=0by default in the kernel and make sure security-misc can’t override it.
Other kernel parameters could still be changed?
If yes this case, OK. It’s messy, but if there’s no better solution
non-debug kernel could do it. Debug kernel shouldn’t do that?
This needs a good technical explanation what issue we’re working around
with this so this can still be understood some years from now by others
(including me).
What makes this also messy is the fact then kernel parameters aren’t
only defined in /etc/default/grub.d and/or at boot time using grub edit
function but also hardcoded and forced in kernel config which is defined
elsewhere. Perhaps drop a note in /etc/default/grub.d, adding a kernel
boot parameter that is ignored by the kernel but as a hint for
users/reviewers (and note for developers) that there are “extra” kernel
parameters defined elsewhere?
Merged.
madaidan via Whonix Forum:
We already blacklist the module in security-misc anyway. If it was needed for something, we’d know by now.
OK.
(I am not sure we have that many security-misc on hosts users yet.)
Yes. The kernel logs can be very useful to an attacker hence why the dmesg_restrict sysctl exists to restrict it to root. There have been many cases of kernel pointer leaks, bypassing kptr_restrict for example.
OK. Please add that rationale to the wiki.
Yes. dmesg_restrict restricts it to CAP_SYSLOG so we can probably remove that capability but CAP_SYSLOG is used for a lot of other functionality so it might break things.
If we do decide to extend the dmesg_restrict sysctl, the user can just use superroot and disable the restrictions.
Kernel patches need to go through kernel.org upstream or any other
appropriate upstream (hardened-linux) that we can use.
Otherwise I am unfortunately convinced that dmesg (replacements) might
give access to kernel pointer leaks which could then be abused.
Though, no dmesg also means we couldn’t know if LKRG kills a process or
panics the kernel. Either legitimate or through a false positive. This
is because LKRG communicates through dmesg. I hope we’re not building
something here which later becomes unusable due to bugs (such as random
poweroff or kernel panic) which nobody can debug since no logs.
madaidan via Whonix Forum:
CONFIG_EFI_VARSmight be good to disable in the host kernel. It exposes a lot of attack surface as it allows you to mess with EFI variables.linux/drivers/firmware/efi/Kconfig at master · torvalds/linux · GitHub
There have been cases of people bricking their computers by accidentally deleting EFI variables. An attacker might be able to do far more by writing specific things to them.
CLIP OS disables this.
Could you please add a ticket to remind ourselves to test the efi vars
config options once we have a few testers using hardened kernel on the
host and EFI?
There are also the
CONFIG_DEV_COREDUMP,CONFIG_WANT_DEV_COREDUMPandCONFIG_ALLOW_DEV_COREDUMPoptions.linux/drivers/base/Kconfig at master · torvalds/linux · GitHub
These seem to add a “device coredump” thing regardless of
CONFIG_COREDUMP(which we disable).
I.e. despite our existing coredump disabling settings that is another
vector for coredumps?
We just need to compile with make CC=clang.
I don’t know. We’d need to test.
We’ll always have the debug/superroot boot modes/kernels.
Likely yes, as it’s not depending on CONFIG_COREDUMP.
Attempted to build VM kernel and install on a EFI kicksecure system and get
mount: /boot/efi: unknown filesystem type ‘vfat’.
CONFIG_VFAT_FS is not set for vm config but is for the host config.
madaidan via Whonix Forum:
Likely yes, as it’s not depending on
CONFIG_COREDUMP.
Ok, please disable.
^ Merged.
Not happy with the realtek cards being broken, though. But at least I’ll added these to the wiki so this becomes at least possible to figure out using “google”.
^ There is now a merge conflict.
^ Could you please document the devices similar to the ones already documented at hardened-kernel?
EFI isn’t supported in VMs. Whonix VMs only support BIOS booting.
No point in enabling a large amount of code barely anyone will be using.
Created a new PR.
@Patrick can you maintain the versioning from now on? Updates are frequent and it can take a while for me to update the versions, create a pull request and then for it to get merged which leaves users on an outdated kernel for a while.
You just need to change the version variable in the build script and update the config (there likely won’t be much change due to us using LTS). You can be notified of new releases by watching the linux-hardened repo: Watchers · anthraxx/linux-hardened · GitHub
kconfig-hardened-check and the KSPP recommended kernel settings have both been recently updated but there isn’t anything relevant to us (as we’ve already done them, they aren’t in our version or they’re for clang).
I am not comfortable with hardened-kernel yet. I can’t give it as much time as it deserves. It’s still not having the maturity that I’ve set as a goal before recommending it to users of Whonix / Kicksecure. (Comparable to other Whonix packages.) See project status (written just today):
hardened-kernel
(And also improved hardened-kernel generally a bit.)
Will take time until these issues are solved.
None of the technical issues are not too hard to solve. Underlying issue are non-technical, lack of time and no current scaling issues of the Whonix project.
Automated test suite:
If I’m understanding this right, we can make the build script create ${working_folder}/packages, then move all the .debs there after compilation:
packages_folder="${working_folder}/packages"
if ! [ -d "${packages_folder}" ]; then
mkdir "${packages_folder}"
fi
mv "${extracted_linux_kernel_sources_folder}/../linux-libc-dev_${version}-rt24-1_amd64.deb" "${packages_folder}/${kernel_config}-libc.deb"
mv "${extracted_linux_kernel_sources_folder}/../linux-headers-${version}-rt24_${version}-rt24-1_amd64.deb" "${packages_folder}/${kernel_config}-headers.deb"
mv "${extracted_linux_kernel_sources_folder}/../linux-image-${version}-rt24_${version}-rt24-1_amd64.deb" "${packages_folder}/${kernel_config}.deb"
/etc/apt/sources.list.d/hardened-kernel-local.list would then contain:
deb [trusted=yes] file:/var/lib/hardened-kernel/hardened-vm-kernel/packages local main contrib non-free
deb [trusted=yes] file:/var/lib/hardened-kernel/hardened-host-kernel/packages local main contrib non-free
We then run apt update and install the kernel image via apt install? e.g.
apt update
apt install hardened-vm-kernel hardened-vm-kernel-headers hardened-vm-kernel-libc
Am I getting this right?
Probably yes.
Yes but that folder cannot just contain packages as far as I know. It needs to be in a file structure that apt understands. I.e. APT repository metadata. To be created with reprepro.
Not sure this was thought or intended to say, just mentioning in case: by changing the filename such as linux-image-${version}-rt24_${version}-rt24-1_amd64.deb to hardened-vm-kernel.deb actually nothing happens. apt does “not much” use the file name for anything. The name of the package is derived from the Debian package metadata (/debian folder).
Getting apt to act on sudo apt install hardened-vm-kernel requries the Debian package metadata to use Package: hardened-vm-kernel somewhere. I don’t know yet how the Debian packaging of linux kernel works yet. Usually for packages (from packages.debian.org) other than linux there is a /debian folder in the source code repository that contains all Debian packaging related files. In case of the linux kernel it seems like that make deb-pkg somehow auto generates that /debian folder during the build process. I wouldn’t know the best approach yet.
make deb-pkg and then use a /debian folder based on Debian’s Debian kernel team / linux · GitLab /debian folder (I speculate that one is better), ormake deb-pkg. (I speculate this way is worse.)That auto generated /debian folder may or may not differ from the /debian folder for linux-image from packages.debian.org.
For educational / development / debugging purposes I’d suggest to experiment with packaging something easy first such as the hello package. Building that package from source. Maybe adding that package to a local APT repository. Other “easily” packaged packages might be genmkfile, helper-scripts, kloak, lkrg. (The software itself might be complex but the packaging process wasn’t the most hard level.)
Can’t we just unpack the deb, edit it, then re-pack it?
e.g.:
ar x "${packages_folder}/${kernel_config}.deb"
tar xf "${packages_folder}/control.tar.xz"
str_replace "..." "..." "${packages_folder}/control"
tar cf ... ...
ar m ... ...