Kernel Hardening - security-misc

Maybe there is a general kernel feature to always treat =0 as =off?

Tolerance level. When a machine check exception occurs for a non corrected machine check the kernel can take different actions.

  • 0: always panic on uncorrected errors, log corrected errors

  • 1: panic or SIGBUS on uncorrected errors, log corrected errors

  • 2: SIGBUS or log uncorrected errors, log corrected errors

  • 3: never panic or SIGBUS, log all errors (for testing only)

As per that link close to the desired outcome to kernel panic on error would be setting tolerant (tolerance level) to 0.

(The kernel manual does not show any example. Might be chimerical settings. Might be setting mce.tolerant=0 is sysctl.)

This could be added to file:

But that as per kernel manual is only for non-corrected errors. For the (maybe?) desired outcome of also kernel panicking as soon as a correctable error is detected I haven’t found a setting yet.

maybe: Not clear yet if changing MCE settings can increase security at all.

1 Like

Got this by e-mail.

Kernel panic is a software routine. It should be executed by the kernel
itself. The MCE handler decides whether the system should panic or not based on
the exception that happened. If you disable MCE and the aforementioned file is
the only place that is called upon identifying such exceptions, the panic will
not happen at all.

And by the way I agree with their concern regarding exposing log messages to
malicious processes. But I would expect them to refer to an study, blog post,
article, code example, etc, to show that how this concern can be valid in real

1 Like

Therefore in absence of any authoritative recommendation to change any mce settings, it’s best we comment it out and don’t change anything related to mce until there is a better argument.

1 Like

Merged, thanks!

Tails enabled 3 boot time kernel options for hardening. Some are caused by changes to upstream security features, another affects TTY which I am not sure how it will impact our current config.

1 Like

That was all previously done already.


Also done.


Thanks anyhow since we could be missing something in theory.

To verify, grepping the source code (or probably enough grepping the security-misc source code) for kernel parameters which should be used or not used would work (which I’ve just done but anyone else welcome to check this as well).


Awesome, great to see more eyes keeping track of potential hardening methods.

1 Like

hidepid can be re-tested once based on Debian bookworm. Maybe pkexec based applications will be no longer broken by hidepid.

1 Like

Anyone had any issues with this?

1 Like

Now merged. Thank you!

1 Like

Based on the recently merged:

We are now allowing kexec:

Are we sure that this is a good idea? Recall, kexec functionality can be abused to replace the existing running kernel and load a malicious kernel (gaining arbitrary code execution).

Sensible hardening guides [1, 2] and security distributions [3] always appear to have it strictly disabled by default.

On the plus side, while having cold boot attack defense is good. The real question is whether the tradeoff of having kexec allowed is worth it knowing the potential downsides?

1 Like

To use kexec, root is required. But if an attack has root access, then it’s game over anyhow.

In a threat model with untrusted root ( Multiple Boot Modes for Better Security: an Implementation of Untrusted Root ) that might be more important.

You could argue that the scope of security-misc should be limited and that cold boot attack defense should be a separate package instead. Then security-misc could disable kexec and cold boot attack defense could re-enable it.

That would allow cold boot attack defense to only be enabled on host operating systems. It would get installed on Kicksecure host operating systems by default but could be omitted in VMs (as it seems it’s not useful there except for development and testing).

1 Like

That makes sense.

Are there any statistics as to the portion of users that install/download Kicksecure to be used on bare metal vs VMs?

Based on my anecdotal evidence most people run it on VMs, though admittedly its a very very small sample size.

1 Like
1 Like
1 Like