Would it be possible to use newer kernel sources for this?
There’s tons of new security features in newer kernels like init_on_alloc, init_on_free, safesetid etc. The stable debian kernel has none of these while the sid one does have them.
It would also be great to use a newer GCC as Debian stable’s GCC doesn’t support plugins like stackleak or randstruct.
Would backports be sufficient?
hi I have used several configurations even of clip os
but break the kernel in live cd
This security if it works correctly
nit_on_alloc, init_on_free, safesetid
grub configuration
ipv6.disable=1 net.ifnames=0 apparmor=1 security=apparmor slab_nomerge slub_debug=FZP mce=0 page_poison=1 pti=on mds=full,nosmt module.sig_enforce=1 audit=1 components union=overlay vsyscall=none init_on_alloc=1 init_on_free=1 l1tf=full,force spectre_v2=on spec_store_bypass_disable=seccomp extra_latent_entropy tsx=off
Backports would be great. Latest version is 5.3 which has all those features.
One thing to be aware of though is that newer kernels often add tons of new attack surface and new vulnerabilities. That’s why grsecurity is using older kernels (4.4 and 4.14). Although, I don’t know how much this will affect us since our kernel disables a lot of things.
Also, here is the port of GRKERNSEC_IO I created Debian paste error
It creates a new config option called CONFIG_SECURITY_IO_RESTRICT and disables the iopl and ioperm calls if it’s set. I haven’t yet tested if those calls are blocked, but it should work.
Please set jitterentropy_rng.ko to built-in.
Related:
Debian bug report: set jitterentropy_rng.ko to built-in
CRYPTO_RNG is a dependency and also has to be built-in.
Merged.
CONFIG_HAVE_LIVEPATCH=y
Should be disabled?
No, the HAVE_* options just say whether your architecture supports that option but doesn’t actually enable that option AFAIK.
CONFIG_HAVE_LIVEPATCH=y is not the same as CONFIG_LIVEPATCH=y
@Patrick have you seen Disable KSM by madaidan · Pull Request #6 · Kicksecure/hardened-kernel · GitHub and More hardening by madaidan · Pull Request #7 · Kicksecure/hardened-kernel · GitHub yet?
No. In this case no e-mail by github received. Strange. Thanks for letting me know.
Enables IOMMU by default
Disables kernel crash dumps and coredumps as they can give an attacker a lot of useful information(the following are disabled because they aren’t really needed, not because they’re a security risk):
Disables TV support
Disables webcam support
Disables radio support
Good stuff.
It also disables CONFIG_PREEMPT. What’s the rationale of that?
Probably security? But I haven’t found any quotes indicating that this is the case.
Disables kernel crash dumps and coredumps as they can give an attacker a lot of useful information
I agree. It’s documented here (but may be slightly outdated since it doesn’t mention how security-misc fixes this):
But why is it useful to disable it in the kernel? Doesn’t security-misc already turn off all sorts of core dumps? Reason: could make debugging harder. Those who want to have a core dump should be able to at least when they get superroot (or boot into recovery mode) and change these settings. Requiring to also reconfigure and recompile the kernel seems a bit much. If there is a strong rationale we can go for it but I don’t think this implements more than we already have?
Enables IOMMU by default
Why force the default? Since already enabled by default through security-misc. Reason: could make debugging harder.
It was disabled with make so it probably depended on something that was disabled.
A core dump can contain a copy of everything in kernel memory. That will contain tons of sensitive information.
An attacker with root can enable them again to get kernel secrets.
There’s not really any harm in enabling it by default.
How?
Should CONFIG_PROC_PAGE_MONITOR be disabled?
Various /proc files exist to monitor process memory utilization:
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
It was called “brain-dead” and a security risk by grsecurty.
It was also used in exploiting rowhammer to gain kernel privileges.
This is necessary for realtime kernel patches to work
Then let’s use apparmor-profile-everything to block write access to these (/etc/sysctl.d and sysctl and whatnot) to prevent root from enabling core dumps. That reaches the same goal but doesn’t worsen debugging.
If there’s an issue now, and someone wants to debug it, we can say “use root, re-enable core dumps”, done.
If there’s an issue when apparmor-profile-everything is default, and someone wants to debug it, we can say “use superroot, re-enable core dumps”, done.
But if core dumps are disabled in kernel and once apparmor-profile-everything is default and someone wants to debug it, we don’t have a good answer. “Need superroot. And need to re-compile your kernel.” We’d need a debug kernel and a regular kernel. But issues producible with the regular kernel may not happen with the debug kernel. So if not needed, let’s not destroy debugging.
Those are disabled anyway.
The same could be said for nearly every other security feature.
Why enable kptr_restrict or dmesg_restrict since they interfere with debugging?
Why remove System.map?
Why not give total, unrestricted access to /proc and /sys?
So many debugging features open up security holes. Some need to be sacrificed.
Besides, the chances an end user is going to need to look at core dumps on a stable kernel is very unlikely. Those are only really needed for developers testing stuff.
Recompiling the kernel isn’t that big of a deal due to hardened-vm-kernel (once it’s finished). We could even have a second package that allows users to add their own custom configurations and still being easy to use.
Things are difficult already. Very difficult.
I know people with university degrees, and engineering working in technology but not information technology. These are as much as that’s possible, “certified intelligent”. Yet, these are incapable to use any Linux desktop distribution. Let alone Whonix. Whonix is operating in a geek sphere. Yet, I don’t want to make it too difficult to make even more geeks give up.
It is my goal to follow the principle of least astonishment.
Disabling debugging can be a bad surprise already. But it’s justified for a security focused distribution. And it can be undo in one step by using root. And in future, it can be undone by using superroot. But disabling these settings and then also removing it from the kernel… That’s two times for the same thing. Even someone who managed to re-enable the debugging sysctl settings (using superroot) could still not debug.
It is also my goal to stay reasonable. I am expecting upcoming discussions. Using reasonable time effort to answer reasonable questions.
Why did you disable core dumps in sysctl settings?
Because, see Core Dumps - Kicksecure
Alright, but why don’t you let even root change these settings, it’s blocked by apparmor-profile-everything?
Because we’re implementing Untrusted Root - improve Security by Restricting Root too.
Alright, I see why core dumps are disabled by default and re-enabling requires superroot. I used superroot to enable core dumps. Why I still can’t get coredumps?
We disabled core dumps in kernel too. You need to recompile your kernel.
Kernel recompilation is pushing it.
Why did you disable coredumps in kernel too if you already disabled the sysctl and blocked root from re-enalbing it using apparmor-profile-everything?
That one I don’t know.
The last answer isn’t reasonable. There needs to be a good answer for that.
Quite a lengthy potentially upcoming discussion. (Can often be shortened by writing documentation.) But super lengthy and complex already. I’d like to avoid layers of complexity if avoidable.
Yes but these are all easily undone in 1 step. Either with root or superoot. Disabling them has a reasonable justification and the process of re-enabling is reasonable too. Kernel recompilation is an extra step on top which isn’t well justified yet. Piling up unjustified things makes the project harder to maintain. Also I don’t want to push the level of complexity to a stage where I myself start to forget things and not see through anymore.
Slim, few people, but these can be very important people. I specifically don’t want to needlessly annoy super geeks too much. If there’s a great rationale for requiring a rain dance they might forgive, but I don’t want to be unreasonable.
Alright. Good point. I’ve now re-enabled coredumps https://github.com/madaidan/hardened-vm-kernel/commit/e6b8c4b4049fe2d98aba8f4de866718106f68a79
I still don’t think coredumps will ever be needed for the average user and “super geeks” would probably be able to re-compile the kernel.
I don’t know why make keeps shifting around preempt stuff. Probably just dependency weirdness.