Bug 1223865

Thank you for the report, Stuart.

Changing component to the appropriate one (scap-security-guide).

(In reply to Stuart Auchterlonie from comment #0)

Hello Stuart,

  thank you for your report. Couple of things need to be clarified WRT to this request. Please see below.

> Description of problem:
> 

> My findings are that disabling net-pf-31 module only prohibits the
> bluetooth service from starting, but does not prevent an explicit
> modprobe of the bluetooth module.

The current form of "kernel_module_bluetooth_disabled" rule for RHEL/6 and RHEL/7 products recommends solely the "bluetooth" module to be disabled:

* https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/xccdf/system/network/wireless.xml#L95 (RHEL/6 case)
* https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/system/network/wireless.xml#L91 (RHEL/7 case)

But this report is correct in the sense former versions of the OVAL check for this rule allowed the OS system feature check to pass when (at least one of) either 'net-pf-31' module, or 'bluetooth' kernel module have been disabled.

Since as clarified in the following paragraph only in the case 'bluetooth' module is explicitly disabled on RHEL/6 and RHEL/7 products both conditions / requirements are satisfied (the bluetooth service fails to start and it's not possible to load bluetooth kernel module even by explicit call of e.g. 'modprobe bluetooth' command), the former version of the underlying OVAL check has been modified (for both RHEL/6 and RHEL-7 products) to explicitly require "install bluetooth /bin/true" option to be present in some of the "/etc/modprobe.d" configuration files. The corresponding upstream patch performing this change is the following:

  [1] https://github.com/OpenSCAP/scap-security-guide/commit/4ac1337d8bbe341cf1e81fdcfaa2bfb0f92cdc16

> 
> Disabling the bluetooth module, but not the net-pf-31 module,
> prevents both the service from starting and explicit module
> loads on RHEL6 and RHEL7, however under RHEL5 the service can
> be started if the net-pf-31 module is not disabled.

The Red Hat Enterprise Linux 5 system is NOT supported by the benchmarks (security checklists) provided by the scap-security-package (provided SSG benchmarks for RHEL-6 and RHEL-7 would not even work on Red Hat Enterprise Linux 5 system). Therefore as of right now there is no plan to modify existing RHEL-6 and RHEL-7 benchmarks in SSG to clarify / support the 'kernel module bluetooth' behaviour / situation on Red Hat Enterprise Linux 5 system (just wanted this to be explicitly stated).

Finally, FWIW regarding the:
* 'install bluetooth /bin/false', vs
* 'install bluetooth /bin/true'

recommendation (former confusion which of the '/bin/false' vs '/bin/true' executables is better to be recommended for disabling the kernel modules in RHEL/6 and RHEL/7 products), the upstream consensus has been made that '/bin/true' is better to be used. Particular upstream change performing this modification are the following:

  [2] https://github.com/OpenSCAP/scap-security-guide/pull/541
  [3] https://github.com/OpenSCAP/scap-security-guide/commit/0053409c311056f5bc4d8430cc752fe4de5fac2c

To summary the current expected situation regarding to kernel modules loading on both RHEL/6 and RHEL/7 system is as follows:
* the XCCDF (the prose) will recommend '/bin/true' binary to be used for disabling,
* the underlying / corresponding OVAL checks will allow both executables ('/bin/true' and '/bin/false' to be specified. Since '/bin/false' is equivalent setting to the '/bin/true' case just has a side effect of printing a warning message that attempt to load particular kernel module failed. This option is kept supported / honoured for compatibility reasons), and finally
* the corrective (remediation) scripts (if particular OS system feature not configured at all) will prefer the '/bin/true' executable when performing the correction (so newly remediated system would have the new agreed approach configured).
  

> 
> 
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible: 100%
> 
> 
> Steps to Reproduce: (RHEL 5)
> * net-pf-31 module disabled, bluetooth module enabled
> - service bluetooth start (fails to start due to not being able to load
> net-pf-31)
> - modprobe bluetooth (succeeds)
> 
> * net-pf-31 module enabled, bluetooth module disabled
> - service bluetooth start (succeeds)
> - modprobe bluetooth (fails to load)
> 
> * net-pf-31 module disabled, bluetooth module disabled
> - service bluetooth start (fails)
> - modprobe bluetooth (fails)
> 
> So RHEL5 appears to need both lines
> 
> Steps to Reproduce: (RHEL6 & RHEL7)
> (For RHEL7 substitute the relevant systemctl cmd)
> 
> * net-pf-31 module disabled, bluetooth module enabled
> - service bluetooth start (fails)
> - modprobe bluetooth (succeeds)
> 
> * net-pf-31 module enabled, bluetooth module disabled
> - service bluetooth start (fails)
> - modprobe bluetooth fails
> 
> Additional info:

Hope the above being helpful.

Regards, Jan.

Verified that above-mentioned approach in handling bluetooth disablement is present in scap-security-guide-0.1.28-2.el6

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, 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://rhn.redhat.com/errata/RHBA-2016-0846.html