this is directed to anyone interested in customized kernels
1)
download kconfig-hardened-check:
https://github.com/a13xp0p0v/kconfig-hardened-check
2) unpack and run:
path_to/kconfig-hardened-check-master/bin/kconfig-hardened-check -c /usr/src/linux-5.13.12/.config

script will list all the options that can be modified to get hardened kernel but it will not modify anything.

reconfigure .config buid kernel and run the tool again

I got down to 19 failed options and preserved all kernel functionality I need.
- some options must be enabled to run virtualbox successfully.
- I disabled all debugging
- some security options sacrifice stability for security (as described when running xconfig)

Obviously, on personal workstation/desktop systems this is not very important but I regarded this as a challenge

I would think a simple list would be safer or an article about kernel hardening with a checklist (or following the hardened gentoo handbook for example). Or checking a copied config file in /home/user/test/.config.

I don't think I would ever run some external script in /usr/src/linux-src. I WOULD STRONGLY ADVICE AGAINST IT.

Thanks for the thought though, but I'm familiar enough with the hardening options in the Kernel already, and I tend to use many of them. And if I have any problems or questions, I can just consult the relevant sections and choices in menuconfig. It's not that much work actually, it's not like these options are hidden among the drivers.

Popov is Linux Kernel Dveloper. Pretty easy to check.
Script is suggested by Whonix:
https://www.whonix.org/wiki/Hardened-kernel
I assume that Whonix is well known name of hardened linux VM
I am using this script for last two years, yes, you can run this script to check the file for flaws located anywhere you want. I thought that this is pretty obvious that one can run check on the file located anywhere you want.


edit:
If you know all this, then obviously this is not for you. Of course experienced user is able to check what this script does (aside from verifying the source) and with minimal effort credibility of the source.

1 members found this post helpful.

here is the list of the options that can be safely enabled/disabled. I would at first make such kernel as secondary and keep kernel that is known too boot until all is tested.
options needed for virtualbox:
CONFIG_TRIM_UNUSED_KSYMS - must be disabled
CONFIG_STATIC_USERMODEHELPER - must be disabled
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY - must be disabled
CONFIG_MODULE_SIG_FORCE - must be disabled

on the laptop I want
CONFIG_HIBERNATION
enabled

when enabled
CONFIG_UBSAN_TRAP
will make kernel purposely unstable

every option is well described when running nconfig/xconfig so user whould know what each option mean. I am running the above setup for two years now so in intel laptops so I think that this is quite safe and does not affect kernel stability.

3 members found this post helpful.

I did a few iterations of HLFS back 15+ years ago, and the main emphasis was on patches, not merely kernel options. When I started that stuff, linux was vulnerable to stack overflow and buffer overflow vulnerabilities. Your options were a paranoid Selinux which RH were bigging up, or Pax & GRSecurity patch suites. There was patches for gcc, glibc, kernel & some individual programs.

I had the impression everybody had tightened their games up, except Selinux. Nearly every bug I was patching for has been developed out of the kernel, & gcc. Features I was adding with patch suites has been implemented in the native programs. But Pax & Grsecurity are still up there. Are you using them?

grsecurity is commercial now. I used it in the past though.

Now, before anyone asks: maintainer is Arch Linux Project Leader & Security Team.

To enable all these options in hardened kernel, more work from the user is needed, so I felt that simple modification of standard kernel is the easiest thing to do.
I am not certain though if kernel hardening is of any interest though.

Default, unmodified kernel had/has some security problems: IPv6 (I disabled it) and BPF (disabled too) are good examples of such issues. Because I don't any efficient way of controlling everything that potentially may cause problems, I use hardening approach and disable everything that I don't need.

1 members found this post helpful.

Hi.

I have a repo for hardened kernel config for Slackware. It used to use grsecurity (hence the repo name), but as it went commercial I switched to KSPP. Haven't updated it in a while, but I'll probably do that once Slackware 15 is released.

I also have a SlackBuild for TPE kernel module (which was part of grsec).

1 members found this post helpful.

What is the consensus on the usefulness (and depth and accuracy) of Enterprise system security evaluation abilities of LYNIS ?

2 members found this post helpful.

I use Lynis (free version) as a source of extra verification of my configurations, I even added/corrected some tests (for LILO, MySQL and PostgreSQL) but from my point of view it is somewhere in the middle. Not all tests are for Slackware (I have disabled some of them) and some need improvement.

2 members found this post helpful.

You can also try few other programs but they are not tweaked for Slackware. Most are geared towards RedHat and Debian/Ubuntu. Nevertheless they partially can diagnose potential issues with Slackware and can point to some hardening options.

very short list:
https://github.com/toniblyx/prowler
https://github.com/lateralblast/lunar
https://github.com/OpenSCAP/openscap/releases
https://github.com/archerysec/archerysec
https://github.com/intrigueio/intrigue-core

interesting is OpenVAS (based on Nessus before Nessus went closed source/commercial)
https://github.com/greenbone/openvas-scanner

1 members found this post helpful.

Thanks guys. I am aware from running Lynis that,m quite naturally, it is not distro specific and therefore must include systemd stuff. I have been able to ignore those concerns. I just wondered if the testing seemed fairly deep and accurate. I have learned a few things from it and made adjustments but besides being not distro specific it is also not SOHO Desktop specific and I haven't run a 24/7 server in over a decade, so currently my concern is a reasonably safe desktop system

FWIW I am presently building a system with a pre-ME era Intel CPU to compare. It is my understanding System76 sells some PCs that have such intrusive "features" disabled but I want to see for myself by comparing how secure pre vs/ post ME operates..

Just curiosity, but have you been using the hardening options which requires GCC plugins? What's your thought on the introduction of security features in the kernel that requires GCC plugins to work? Or the topic in general.. It has more to do with GCC actually, and the way they have now changed some policies and ways of doing things.

I don't like it much to be frank, so I haven't been using those options requiring GCC Plugins, although I would want to use them. I just don't like the idea of GCC plugins. Seems like something that can fracture things alot in the future.

And well, in the context of Slackware, has anyone been using GCC Plugins yet?

2 members found this post helpful.