content icon indicating copy to clipboard operation
content copied to clipboard

Offline remediation of fstab permissions fails

Open kingsleyzissou opened this issue 3 years ago • 1 comments

Description of problem:

When remediating any of the Restrict Partition Mount Options the remediation fails in offline mode i.e. xccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec. The remediation script checks the /proc/mounts which is unavailable even if the fstab file has been created.

SCAP Security Guide Version:

scap-security-guide-0.1.60-7.el8.noarch

Operating System Version:

RHEl 8.7 & RHEL 9.1

Steps to Reproduce:

  1. Configure a blueprint with moutnpoint options and oscap configuration
  2. Build image with osbuild-composer

Actual Results:

Remediation does not run at all for this since the evaluation result is unknown:

Title
	Add nodev Option to /home
Rule
	xccdf_org.ssgproject.content_rule_mount_option_home_nodev
Ident
	CCE-81048-1
Result
	unknown

Expected Results:

Offline remediation of the /etc/fstab file

Additional Information/Debugging Steps:

Logs:

I: oscap: Evaluating definition 'oval:ssg-mount_option_home_nodev:def:1': Add nodev Option to /home.
I: oscap:   Evaluating partition test 'oval:ssg-test_home_partition_nodev_optional_yes:tst:1': nodev on /home optional yes.
I: oscap:     Querying partition object 'oval:ssg-object_home_partition_nodev_optional_yes:obj:1', flags: 0.
I: oscap:     Creating new syschar for partition_object 'oval:ssg-object_home_partition_nodev_optional_yes:obj:1'.
I: oscap:     I will run partition_probe_main:
E: oscap:     Can't open /proc/mounts: errno=2, No such file or directory.
W: oscap:     Can't receive message: 125, Operation canceled.
E: oscap:     Recv: retry limit (0) reached.
I: oscap:   Test 'oval:ssg-test_home_partition_nodev_optional_yes:tst:1' evaluated as (null).

/etc/fstab file:

UUID=aadca82e-07bc-402e-b0da-c0db4ddd7446	/	xfs	defaults	0	0
UUID=01134d9b-f4db-44e4-a41b-daecb059ad94	/boot	xfs	defaults	0	0
UUID=29da473d-5691-4a31-b411-f9be136283a0	/home	xfs	defaults	0	0
UUID=18b14985-010c-4b9b-a161-d60476785ce3	/tmp	xfs	defaults	0	0
UUID=9b3253b8-ab72-422b-bf27-a1987a131194	/usr	xfs	defaults	0	0
UUID=ffcb7873-6c88-4a74-b6c7-3b8b1588dcf7	/var	xfs	defaults	0	0
UUID=9baf05e5-7e31-47ba-9778-108c949de00f	/var/log	xfs	defaults	0	0
UUID=b9ba75a7-e645-4626-96c9-9eba856df36a	/var/log/audit	xfs	defaults	0	0
UUID=d2383109-5e44-433c-b630-e5677b812e6e	/var/tmp	xfs	defaults	0	0
UUID=7B77-95E7	/boot/efi	vfat	defaults,uid=0,gid=0,umask=077,shortname=winnt	0	2

kingsleyzissou avatar Aug 15 '22 14:08 kingsleyzissou

In this case, we don't really have an alternative for the offline check. Maybe these rules will need to be performed in a different way, applying standalone remediations only for example.

ggbecker avatar Aug 15 '22 16:08 ggbecker

Ok, as I understood, the OVAL check for the mount_option_home_nodev rule, which actually uses the mount_option template, is written in a way that OpenSCAP scanner, during runtime, will use a probe which checks runtime settings by reading the /proc/mounts file.

The /proc/mounts file obviously doesn't exist in a offline system, causing the assessment to fail.

So, the way to check file system mount options in a offline system should use probes which doesn't rely on "pseudo-filesystems". This could be done in OVAL using the textfilecontent54_object, for example. But the runtime check is still valid for online systems. So, based on internal discussions, I agree it makes sense to have a separate rule for offline systems.

marcusburghardt avatar Oct 04 '22 12:10 marcusburghardt

Another option is to expand mount_option template (criteria + tests) to include alternative source for mount options (fstab).

evgenyz avatar Oct 19 '22 13:10 evgenyz