We can make our own whonix-kernel package and make it conflict with other kernel packages.
Sounds good, but I am not convinced yet that package should conflict with Debian provided kernels. For user freedom, easy debugging / comparison co-installation should be possible.
Even multiple Debian kernels (various versions) installed at the same time don’t cause issues. A higher version number (or something) can make it the grub default boot option.
I’m working on a custom kernel config. I’m currently compiling it. I’ve gotten rid of a few thousand config options from the default debian config.
Should I enable the KSPP recommend settings and some other hardening settings too?
Not sure. But not important at this time. Could be done on future iteration. Or different packages / options?
Since non-Whonix specific… Any package name ideas?
I guess instructions or automation through a package for a hardened Linux could be interesting for many not wanting or not affording grsec subscription.
Perhaps start with less hardening that works for many users first to get a wide user base and potentially break things through hardening later to have more eyeballs watching?
It isn’t necessarily Whonix specific but it will be VM specific. Maybe something like “hardened-kernel” or “whonix-kernel”.
Here is the kernel configuration I’m working on: Debian paste error
I’ve just tested it on virtualbox and the only error I’m seeing so far is whonix-firewall failing to load since IPv6 isn’t included in the kernel config at all.
It looks like whonix-firewall just blocks IPv6 traffic but what is the point of this when IPv6 is disabled?
Better. Just let’s not use linux-hardened since another project has already taken that name.
Just in case. Can’t be careful enough.
As one of the most weird leaks ever (Whonix was unaffected but still), see this one:
It’s related to this:
ipv6 || true
Note: http://ip6only.me works in Tor Browser. No need to break that. Not sure that requires kernel support.
How does that work: Tor Browser talks to Tor directly (more or less, effectively yes, anon-ws-disable-stacked-tor). And some Tor exit relays support IPv6. Even if Whonix-Gateway has IPv6 disabled, Tor can tunnel IPv6 through its IPv4.
Whonix-Workstation does not have IPv6 disabled.
I don’t see how an IPv6 leak would be possible when the code doesn’t even exist in the kernel.
ip6tables would still spam the logs with errors.
Should I also get rid of kernel modules entirely (unset CONFIG_MODULES)?
All needed modules can be built into the kernel directly by switching them to
y options instead of
Breaks virtualbox guest additions?
There are some interesting modules which I didn’t get to yet such as LKRG: LKRG - Linux Kernel Runtime Guard
Also another maybe upcoming kernel module related to kernel ISN (Add research idea for Linux TCP Initial Sequence Numbers may aid correlation (#16659) · Issues · Legacy / Trac · GitLab).
We can likely compile those directly into the kernel rather than using loadable modules.
Does this make things more fragile, likely to break? Speculate not many people built-in virtualbox guest addition modules or other modules.
(And host kernel including virtualbox host module build-in? If we want to maintain just one kernel (enough…) then built in virtualbox guest and host module?)
Do we gain security by using a kernel without module support compared to non-module support?
As of now, not all modules are load all the time. But without module load support, is everything load all the time?
Then we’d need a virtualbox and a non-virtualbox kernel? Or non-virtualbox VMs are just to bite the bullet of having a useless built-in module?
This kernel won’t be able to be used on hosts. Otherwise we’d need to enable all hardware config options which would drastically increase the time needed to compile and add attack surface.
This is for VMs only. We can make a kernel for hosts if you want which would be separate from VMs but that’d take too long to compile and won’t be able to be compiled during package upgrades. It’d have to be pre-compiled.
Yes, it prevents loading any module to add attack surface or load a malicious module.
I think so. Not sure.
Yes. The built-in module doesn’t add much and shouldn’t be a problem for non-virtualbox VMs.
In doubt lets start simple, see how things go and more hardening later? Otherwise, if someone experiences instability, it may be hard to pinpoint what the cause is.
That might actually be less secure then.
This will probably be contested.
Understood. Makes sense. Package name: hardened-vm-kernel or something like that? (“hardened vm kernel” might have some search results, hopefully we’re not reinventing here. I remember Ubuntu years ago had a VM specialized kernel.)
Module loading requires root. “trusted” root. But root could as well as modify the kernel on the disk so next reboot something else will be booted? This would be far more useful if at reboot there was an integrity check which would refuse to boot any tampered kernel images. Related to
- Verified Boot - Kicksecure
- enable Linux kernel gpg verification in grub and/or enable Secure Boot by default
As an alternative to make all modules built-in rather than dynamically load… What about loading all modules at early boot time and then disabling module loading? Would that be as good as disabling module loading at kernel compile time?
Sure. I was only giving ideas.
Only the needed modules will be compiled so it might not be.
hardened-vm-kernel sounds good. I don’t think we’re reinventing. I’ve never heard of a hardened kernel designed for virtual machines before that isn’t grsec.
I think we should still protect the kernel from the root user.
We can fix that with the system wide MAC policy or verified boot.
Not sure. Needs more research.
Would RTC and audio be needed in VMs?
I can remove both of them to reduce compilation time.
Maybe not hardened but specialized kernels for VM did and do exist.
Ubuntu had something. Search term:
But Ubuntu thing was a thing of 2013 or earlier. Might have been a whole distribution flavor only for virtual machines.
audio: workstation yes, gateway no.
RTC: Not sure.
We need a hardware clock for sure? Otherwise when VM would start it would not have any clock except perhaps some hardcoded time/date information at all? But not necessarily an RTC? Dunno if VirtualBox provides an RTC and a hardware clock or only an hardware clock which is also an RTC. Search term:
site:virtualbox.org real time clock site:virtualbox.org RTC
Haven’t found something relevant yet.
I haven’t found any “relevant” disadvantages of not having an RTC yet. Only of not having no hardware clock at all.
Could just try if anything breaks without RTC?
Best tested in non-Whonix / non-Kicksecure, plain Debian VM. At boot, time without help of any network synchronization daemons need to be somewhat correct. Shouldn’t rely on internet to fetch. Without any initial time, it’s hard/impossible to securely fetch time from remote. Opens up for many attacks as per:
Could you please (based on above perhaps) provide instructions on how to compile the kernel with your custom kernel config? That would allow me and perhaps others to test this sooner rather than later.
IMO we should limit the custom kernel to the WS as the risk of leaks would be too great if we applied it to the GW too. We simply don’t know what every module does or how they interact with each other to deliver the same leak protection we have now.
No untrusted software should be running there so there’s no danger of some disabled module being enabled without users’ consent.
I think the kernel config package should be replicated once for each different hypervisor to keep things clean and simple.
There’s no reason to have modules relevant to VBox and Xen enabled for KVM users and vice versa. If we’re about decreasing attack surface let’s go all the way.
@madaidan How active is Linux-Hardened upstream? How much can we rely on it’s author to keep maintaining his fork until KSPP merges the missing features? There’s nothing worse than doing a bunch of effort based on someone’s dead code.
Do the patches work with Debian vanilla source tarball? We should not base on kernel.org’s code.