Extend bls_entries_options to check for runtime and $kernelopts

[yuumasato]

Description:

• Add check for runtime kernel options (/proc/cmdline)
• Extend set of checks to support $kernelopts
  • Fedora and RHEL8 may not have the kernel options directly in the entries in /boot/loader/entries/*.conf, but rather be defined by $kernelopts which are sourced via /boot/grub2/grubenv.
• Also make sure that /boot/grub2/grubenv will retain the configured kernel options.
  • Running grub2-mkconfig or kernel update may update /boot/grub2/grubenv and strip kernel options away if they are not set in /etc/default/grub (GRUB_CMDLINE_LINUX).

[evgenyz]

Okay, I have just one question: why you are adding all this GRUB2-related specifics into the bls_entries_option template instead of grub2_bootloader_argument?

My point is that I think that checking grub2 configuration here is as irrelevant as, for example, checking some zipl configuration. It would be an abomination template for the single purpose of having just one bls_option_* rule(s) for all profiles products? Would it worth the hassle? How would we handle the case where GRUB2 boot-loader is replaced with something else in regular Fedoras (ARMs)?

[yuumasato]

Okay, I have just one question: why you are adding all this GRUB2-related specifics into the bls_entries_option template instead of grub2_bootloader_argument?

That template does not address BLS, which should be the preferred method for RHEL8.

My point is that I think that checking grub2 configuration here is as irrelevant as, for example, checking some zipl configuration.

BLS unifies the boot configuration format, but (AFAIK) the way bootloaders update the kernel and carry forward these options is not unified. And the rule should also ensure that kernel updates don't lead the system out of compliance.
In the end the rule should ensure:

• Current boot is compliant
• Next boots will be compliant
• New Kernel will be installed and stay compliant ( I don't know how RHCOS handles this)

It would be an abomination template for the single purpose of having just one bls_option_* rule(s) for all profiles products?

So far the templates have been pretty much shared, do we have a template exclusive to one product?
And this case it is not a different product, but different architecture.

Would it worth the hassle?

Maybe, what is the alternative?
Specific profile or DS for other arches doesn't seem a good approach, majority of rules are the same.
Separate rules for arch specific checks seem appropriate, but I'd like to avoid having a ton of rules added to a profile to support a different arch. Check this draft work. So #5888 simplifies them and hopefully we can merge unify them.

How would we handle the case where GRUB2 boot-loader is replaced with something else in regular Fedoras (ARMs)?

The template can have checks for the arch/bootloader and just perform the BLS check.

[evgenyz]

My vision of ideal is to have zipl_everything_is_ok, grub2_everything_is_ok and bls_everything_is_ok. Products would have a combination of for example grub2_everything_is_ok + bls_everything_is_ok, but where ^(?:.*\s)?\$kernelopts(?:\s.*)?$ would be checked in grub2_....

We can of course have bootloader_everything_is_ok template that would handle the difference based on CPE, availability of configs, files, packages, and then in theory every profile could be able to contain just this single rule. But it is a path to a rule that would be called "system_is_security_compliant" :)

    - zipl_audit_argument
    - zipl_audit_backlog_limit_argument
    - zipl_slub_debug_argument
    - zipl_page_poison_argument
    - zipl_vsyscall_argument
    - zipl_vsyscall_argument.role=unscored
    - zipl_vsyscall_argument.severity=info    

Why this is a problem?

[yuumasato]

My vision of ideal is to have zipl_everything_is_ok, grub2_everything_is_ok and bls_everything_is_ok. Products would have a combination of for example grub2_everything_is_ok + bls_everything_is_ok, but where ^(?:.*\s)?\$kernelopts(?:\s.*)?$ would be checked in grub2_....

I think it is more about the configuration format than the actual bootloader used. $kernelopts may be a GRUB2 particularity but it is used in BLS formated boot entries. And note that zIPL rules are also about configuring BLS format.
Doesn't RCHOS also use GRUB2 underneath the hood?

About template grub2_bootloader_argument, once rules checking BLS format are implemented, RHEL8 can stop using it, RHEL7 will have to stick to it though.

I understand the concern that this single template can become complex. But at the same time I'd like to avoid having too many templates for kernel options.

I will move forward with multiple templates, and see how it goes.
One side effect of this approach is that it will restrict us to separate rules for a given kernel option on different arches.

    - zipl_audit_argument
    - zipl_audit_backlog_limit_argument
    - zipl_slub_debug_argument
    - zipl_page_poison_argument
    - zipl_vsyscall_argument
    - zipl_vsyscall_argument.role=unscored
    - zipl_vsyscall_argument.severity=info    

Why this is a problem?

This is not a strong blocker for me, I'm mainly concerned about number of "duplicate" rules that can get into the scene if we consider other settings and other bootloaders.
And the zipl_audit_argument and bls_audit_option are so similar that it feels like duplicated code.
But I realize we don't have a good way to handle description and OCIL for zIPL and GRUB particularities in a single rule.

[yuumasato]

Given the trends set by #5908 and #6088, it looks like the way to go is to create a linux BLS like-non-compliant template, instead of modifying bls_entries_options.
Closing.