[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

kernel recompilation for better hardening

^ 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 https://www.whonix.org/wiki/Hardened-kernel#Disabled_Devices?

1 Like

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.

1 Like

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: https://github.com/anthraxx/linux-hardened/watchers

1 Like

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).

1 Like

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):
https://www.whonix.org/wiki/Hardened-kernel#Project_Status

(And also improved https://www.whonix.org/wiki/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:

1 Like
1 Like

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?

1 Like

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.

  • Perhaps build the kernel image without using make deb-pkg and then use a /debian folder based on Debian’s https://salsa.debian.org/kernel-team/linux /debian folder (I speculate that one is better), or
  • Hack the environment variables / autogeneration code of Linux’s upstream make 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.)

1 Like

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 ... ...
1 Like
2 Likes

Possibly.

1 Like
1 Like

Contacted Colin Childs @Phou through twitter DM.

hello
since you’ve previously worked on coldkernel…
any chance to get you interested in https://github.com/Whonix/hardened-kernel ?
not grsecurity but using https://github.com/anthraxx/linux-hardened and a hardened kernel config
https://whonix.org/wiki/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 https://github.com/anthraxx/linux-hardened let alone hardened-kernel-config / https://github.com/Whonix/hardened-kernel.

2 Likes

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”.

1 Like

Yes, very much so!

1 Like

How is https://paste.debian.net/hidden/bbabc3b9/?

1 Like

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

security vulnerabilities

Unless there is a reason not to do this?

or both

security vulnerabilities [1]?

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?

https://github.com/Whonix/tirdad#tcp-isn-cpu-information-leak-protection

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 admin | 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?

1 Like

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 https://paste.debian.net/hidden/46d2b42e/

1 Like

Btw the sandbox-app-launcher link is https://github.com/Whonix/sandbox-app-launcher which doesn’t exist. Should I change it to https://github.com/madaidan/sandbox-app-launcher or will you fork it?

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]