STIGViewer Support

OL 9 must be configured so that all system device files are correctly labeled to prevent unauthorized modification.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-271769OL09-00-002500SV-271769r1092019_ruleCCI-000366medium
Description
If an unauthorized or modified device is allowed to exist on the system, there is the possibility the system may perform unintended or unauthorized operations.
STIGDate
Oracle Linux 9 Security Technical Implementation Guide2026-02-17

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (8) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
CFG-02Secure Baseline Configurations
0.50
CFG-02.7Approved Configuration Deviations
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (100) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-12Session Termination
1.00
AC-16(1)Dynamic Attribute Association
1.00
AC-17(1)Monitoring and Control
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-24(1)Transmit Access Authorization Information
1.00
AC-25Reference Monitor
1.00

+90 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.1
1.00
3.4.2
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

PR.PSPlatform Security
0.50

Who does this work

10 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-271769r1092019_chk)

Verify that OL 9 configures all system device files to be correctly labeled to prevent unauthorized modification. List all device files on the system that are incorrectly labeled with the following commands: Note: Device files are normally found under "/dev", but applications may place device files in other directories and may necessitate a search of the entire system. $ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n" $ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n" Note: There are device files, such as "/dev/dtrace/helper" or "/dev/vmci", that are used for system trace capabilities or when the operating system is a host virtual machine. They will not be owned by a user on the system and require the "device_t" label to operate. These device files are not a finding. If there is output from either of these commands, other than already noted, this is a finding.

Fix Text (F-75726r1092018_fix)

Configure OL 9 to correctly label all system devices. Restore the SELinux policy for the affected device file from the system policy database using the following command: $ sudo restorecon -v <device_path> Substituting "<device_path>" with the path to the affected device file (from the output of the previous commands). An example device file path would be "/dev/ttyUSB0". If the output of the above command does not indicate that the device was relabeled to a more specific SELinux type label, then the SELinux policy of the system must be updated with more specific policy for the device class specified. If a package was used to install support for a device class, that package could be reinstalled using the following command: $ sudo dnf reinstall -y <package_name> If a package was not used to install the SELinux policy for a given device class, then it must be generated manually and provide specific type labels.