CPU specific options and the kernel cmd line about kernel-hardening-checker

[a13xp0p0v]

Now kconfig-hardened-check supports checking kernel cmdline parameters.

Cool!

usage: kconfig-hardened-check [-h] [--version] [-p {X86_64,X86_32,ARM64,ARM}]
                              [-c CONFIG]
                              [-l CMDLINE]
                              [-m {verbose,json,show_ok,show_fail}]

A tool for checking the security hardening options of the Linux kernel

optional arguments:
  -h, --help            show this help message and exit
  --version             show program's version number and exit
  -p {X86_64,X86_32,ARM64,ARM}, --print {X86_64,X86_32,ARM64,ARM}
                        print security hardening preferences for the selected architecture
  -c CONFIG, --config CONFIG
                        check the kernel kconfig file against these preferences
  -l CMDLINE, --cmdline CMDLINE
                        check the kernel cmdline file against these preferences
  -m {verbose,json,show_ok,show_fail}, --mode {verbose,json,show_ok,show_fail}
                        choose the report mode

[a13xp0p0v]

Hi @morfikov, thanks for your ideas.

1. I think we can group AMD_IOMMU recommendations with the corresponding ones for Intel using OR.
   That would allow to avoid incorrect FAIL reports.

2. Parsing the kernel command line is a nice feature, it's on my TODO list. Moreover, we can get it from /proc/cmdline without additional privileges, which is nice.

I'm going to work on kconfig-hardened-check in the coming days.
If you want to participate, come on, your pull requests will be welcome!

[Bernhard40]

I always seen this project scope as simple kernel config checker not running system audit tool and I believe in old unix mantra Do One Thing and Do It Well so I'm skeptical about this additions. Taking /proc/cmdline into account would mean same config would yield different result across systems. Having OR between amd and intel features make it less useful for distros which would want them all.

I think end users are capable of ignoring amd warnings when they have intel cpu and the opposite and also be aware o what they added to their cmdline.

[a13xp0p0v]

Hi @Bernhard40

Having OR between amd and intel features make it less useful for distros which would want them all.

Hm, you are right. I would agree on that point.

Taking /proc/cmdline into account would mean same config would yield different result across systems

I would propose a compromise: add a separate flag for checking /proc/cmdline (disabled by default).
Is it OK for you?

In fact, I see checking cmdline parameters as a very big improvement.
There are several important cases when checking kernel config is not enough for a correct conclusion about the kernel security.
Examples: mitigations, page_poison, init_on_alloc/init_on_free and some others.

[Bernhard40]

I would propose a compromise: add a separate flag for checking /proc/cmdline (disabled by default).
Is it OK for you?

I don't mind if you are ready to maintain it.

In fact, I see checking cmdline parameters as a very big improvement.
There are several important cases when checking kernel config is not enough for a correct conclusion about the kernel security.

Yes but for now checking kernel config is the only thing this project ever promised (see readme). Conclusions about kernel security needs expanding the project scope which may be a rabbit hole as if you add cmdlne support then sysctl support should be next etc.

[a13xp0p0v]

@Bernhard40, I'll do my best.