^ 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 ... ...Possibly.
Contacted Colin Childs @Phou through twitter DM.
hello
since you’ve previously worked on coldkernel…
any chance to get you interested in GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. - https://www.kicksecure.com/wiki/Hardened-kernel ?
not grsecurity but using GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening and a hardened kernel config
hardened-kernel
^ Patrick
What this project needs most is outreach. Getting developers interested that previously worked on packaging grsecurity, grsecurity installers, etc. Most simply gave up after grsecurity was gone. Very few know about the existence of GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening let alone hardened-kernel-config / GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized for virtual machines. - https://www.kicksecure.com/wiki/Hardened-kernel.
I think it might be a good idea to create a large post detailing all of our recent security hardening work including security-misc, apparmor-profile-everything, hardened-kernel, sandbox-app-launcher, hardened_malloc, LKRG and tirdad and the issues they aim to fix, similar to The Problem with Security Guides and How We Can Fix It. It could have the potential to attract a lot of new people as it’s not just kernel stuff but also MAC, sandboxing, memory allocators etc.
I could write something up if you’re interested. A good title may be something like “Fixing the Desktop Linux Security Model”.
Yes, very much so!
Looks really good already. I have to read more carefully, but I guess it will only be nitpicks from my side. You could also post the draft here: https://www.whonix.org/wiki/Fixing_the_Desktop_Linux_Security_Model
Could you please convert
security vulnerabilities [1]
to
Unless there is a reason not to do this?
or both
I guess both ([number] style + forum links) would be good to - because then this can be re-posted on mailing lists.
tirdad is a kernel module that aims to prevent TCP Initial Sequence Number (ISN) based information leaks by randomizing the TCP ISNs [6]. This is more of anonymity feature than a security feature.
Did you see this security argument here?
Could you please mention maybe SAK, login spoofing, the mostly sudo security theater and how multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode would fix that?
Worth mentioning all Upcoming Security Enhancements?
Untrusted Root User 
deactivate malware after reboot from non-root compromise 
Mount Options Hardening 
Disable SUID Binaries Whonix is a security, privacy and anonymity focused Linux distribution. Recently, we’ve been focusing a lot on important security hardening measures and fixing architectural security issues within the desktop Linux security model.
Could you please make more clear that any desktop Linux distribution is affected?
Most are part of security-misc so there’s not much reason to mention them separately. I extended the security misc section a bit and added your suggestions Debian paste error
Btw the sandbox-app-launcher link is GitHub - Kicksecure/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox https://www.kicksecure.com/wiki/sandbox-app-launcher which doesn’t exist. Should I change it to GitHub - madaidan/sandbox-app-launcher: An app launcher to start apps in a restrictive sandbox or will you fork it?