Bug 2081688

Hello Jan,
just one question concerning the need to check and remediate rules syscl_kernel_core_pattern and sysctl_kernel_core_uses_pid together. We can specifya requirement stating that the rule X requires rule Y to be selected, othervise the rule X will not be evaluated. We will of course put both rules into the OSPP profile. So if we state that sysctl_kernel_core_pattern requires sysctl_kernel_core_uses_pid and someone uses tailoring to remove sysctl_kernel_core_uses_pid, none of the rules will be evaluated. Is this acceptable?

That sounds perfect.

For the record, after further discussions, it was decided not to enforce the requirement between syscl_kernel_core_uses_pid and syscl_kernel_core_pattern. syscl_kernel_core_pattern might be in some cases used without syscl_kernel_core_uses_pid and requirement can't be specified on profile base.

So, here is the final state. Due to problems encountered, the final state is:
- there is a new rule sysctl_kernel_core_pattern_empty_string which replaces sysctl:kernel_core_pattern in RHEL9 OSPP. This rule sets kernel.core_pattern to ''.
- there is another new rule sysctl_kernel_core_uses_pid, added to RHEL9 OSPP profile as well. The rule sysctl_kernel_core_pattern_empty_string requires rule sysctl_kernel_core_uses_pid. Moreover, sysctl_kernel_core_pattern_empty_string conflicts with sysctl_kernel_core_pattern and vice versa, since both rules modify the same config option.

Sounds like a good plan. Thank you.

Fixed upstream: https://github.com/ComplianceAsCode/content/pull/9285

This this is still ON_QA, I'm adding it here instead of filing a new BZ.

The

    sysctl_kernel_core_pattern_empty_string

rule does what it sets out to do, ensuring that /proc/sys/kernel/core_pattern has '' :

    {{{ ocil_sysctl_option_value(sysctl="kernel.core_pattern", value="''") }}}


This, however, does not disable coredumps:

# ulimit -c unlimited

# ls
segfault  segfault.c

# grep '' /proc/sys/kernel/core_*
/proc/sys/kernel/core_pattern:''
/proc/sys/kernel/core_pipe_limit:16
/proc/sys/kernel/core_uses_pid:0

# ./segfault 
Segmentation fault (core dumped)

# ls
"''"   segfault   segfault.c


(The coredump is written to a file named '' )

For the disablement to work, /proc/sys/kernel/core_pattern needs to actually be empty, as in - zero bytes of text, plus a newline.

A.k.a. the equivalent of

echo > /proc/sys/kernel/core_pattern

Matus, per comment 18 this bugzilla FAILS_QA. Would you like to update the status accordingly to bring this to engineering's radar, or should I  move it back to ASSIGNED?

Yes, we are already looking into it.

For the record, we had a chat with Gabriel Gaspar Becker on gchat where we discovered that sysctl (procps-ng) doesn't support setting empty values on RHEL-9.0 (and older), but does on RHEL-9.1+

# sysctl -p
sysctl: /etc/sysctl.conf(11): invalid syntax, continuing...

So if ComplianceAsCode upstream maintains only one version for RHEL-9 overall, we have to either

 * go back to |/bin/false

 * unify the implementation details under a rule that simply disables kernel coredumps,
   checking for multiple approaches, and where the remediation may change across RHEL-9 minors

In the end, it was decided to go back to the |/bin/false approach, effectively switching back to the rule syscl_kernel_core_pattern.
https://github.com/ComplianceAsCode/content/pull/9384

I object to the decision in comment 24.

In RHEL 9.1, sysctl -p and sysctl --system work just fine:

# sysctl kernel.core_pattern
kernel.core_pattern = /usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
# echo kernel.core_pattern= > /etc/sysctl.d/core_pattern.conf
# sysctl --system
[...]
# sysctl kernel.core_pattern
kernel.core_pattern = 

So there isn't any reason not to go with the empty core_pattern (and empty string) on RHEL 9.1+.

For RHEL 9.0 (bug 2117612), the same will work if fix for bug 2052536 gets backported to RHEL 9.0.z, which I talked about to procps-ng maintainer already.

In general, the question is if the SCAP rules should use and promote sysctl --system rather than invoking /usr/lib/systemd/systemd-sysctl. After all, ExecStart=/usr/lib/systemd/systemd-sysctl is what /usr/lib/systemd/system/systemd-sysctl.service defines on RHEL 8+ so that's the mechanism which will be used after reboot to set the kernel values.

Vojta mentioned that the command used to actually set the value in runtime is

 /sbin/sysctl -q -n -w

which I see in https://github.com/ComplianceAsCode/content/blob/master/shared/templates/sysctl/bash.template.

But if that's the case, there's actually no problem with the empty value at all because it seems to be accepted even on RHEL 9.0 just fine:

# sysctl kernel.core_pattern
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
# sysctl -q -n -w kernel.core_pattern=
# sysctl kernel.core_pattern
kernel.core_pattern = 
#

So can we go back to the question of -- what would

    {{{ ocil_sysctl_option_value(sysctl="kernel.core_pattern", value="") }}}

instead of the current

    {{{ ocil_sysctl_option_value(sysctl="kernel.core_pattern", value="''") }}}

actually break, on RHEL 9.1 and on RHEL 9.0?

(In reply to Jan Pazdziora from comment #26)
> Vojta mentioned that the command used to actually set the value in runtime is
> 
>  /sbin/sysctl -q -n -w
> 
> which I see in
> https://github.com/ComplianceAsCode/content/blob/master/shared/templates/
> sysctl/bash.template.
> 
> But if that's the case, there's actually no problem with the empty value at
> all because it seems to be accepted even on RHEL 9.0 just fine:
> 
> # sysctl kernel.core_pattern
> kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
> # sysctl -q -n -w kernel.core_pattern=
> # sysctl kernel.core_pattern
> kernel.core_pattern = 
> #
> 
> So can we go back to the question of -- what would
> 
>     {{{ ocil_sysctl_option_value(sysctl="kernel.core_pattern", value="") }}}
> 
> instead of the current
> 
>     {{{ ocil_sysctl_option_value(sysctl="kernel.core_pattern", value="''")
> }}}
> 
> actually break, on RHEL 9.1 and on RHEL 9.0?


The problem isn't the runtime on-CLI setting, it's the sysctl.conf setting.

# grep -n core_pattern /etc/sysctl.conf
13:kernel.core_pattern =

# sysctl -q -n -p
sysctl: /etc/sysctl.conf(13): invalid syntax, continuing...

It's true that systemd-sysctl is its own independent implementation that *does* support empty strings, so it would /technically/ work, ... but it would also break 'sysctl -p' for any admins who would want to modify sysctl.conf during runtime.

It's true that, if the SCAP content supports it, we could use the empty-string on 9.1+ and use something else for 9.0. Actually, we could even use "''", because the default core limit is 0, even on clean RHEL, probably because systemd-coredumpd is handling it by default, so there was no reason for users to generate coredumps. However segfaulting services /could/ then generate dumps.

Pulling in (and waiting for) another 9.0.z package for a minor change like this might not be worth it if the only downside for '|/bin/false' is that it prints "(core dumped)".

The PR https://github.com/ComplianceAsCode/content/pull/9396 that we believe fixes the issue has been merged.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scap-security-guide bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8131