Bug 1902227

Summary: Device /dev/isst_interface is labeled with device_t which breaks STIG compliance
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.3CC: lvrabec, mmalik, plautrba, ssekidde
Target Milestone: rcKeywords: AutoVerified, Triaged
Target Release: 8.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The /dev/isst_interface had no particular label defined in the policy. Consequence: The generic device_t label was assigned which is not allowed by STIG. Fix: Define cpu_device_t type in the policy for /dev/isst_interface and an appropriate file transition. Result: The /dev/isst_interface file is now labeled as cpu_device_t.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 14:58:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Renaud Métrich 2020-11-27 12:43:07 UTC
Description of problem:

A customer running a system with "Intel Xeon Gold" CPU has device /dev/isst_interface labeled with "device_t".
When applying STIG compliance, the rule "SV-86663r1_rule" fails ("All system device files must be correctly labeled to prevent unauthorized modification.").

I know there is no RHEL8 STIG profile yet but this rule will likely exist.

This /dev/isst_interface is set up by Interl Speed Select Interface kernel module (drivers/platform/x86/intel_speed_select_if/isst_if_common.c) and consumer is a binary named /usr/bin/intel-speed-select ("bin_t").

Since the device is used to control CPU stepping, I think the character device should be labeled with "cpu_device_t".


Version-Release number of selected component (if applicable):

selinux-policy-3.14.3-54.el8.noarch and Upstream policy (at least Fedora Rawhide)


How reproducible:

Always on customer system, I don't have the hardware to reproduce.


Additional info:

The module is a new feature of 8.3 kernel apparently, controlled by CONFIG_INTEL_SPEED_SELECT_INTERFACE=m option.

Suggested fix: same context as "microcode"

policy/modules/kernel/devices.if:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
filetrans_pattern($1, device_t, cpu_device_t, chr_file, "isst_interface")
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

.fc:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
/dev/isst_interface	-c	gen_context(system_u:object_r:cpu_device_t,s0)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Comment 1 Renaud Métrich 2020-11-27 12:43:45 UTC
Handle 0x0004, DMI type 4, 42 bytes
Processor Information
        Socket Designation: CPU #000
        Type: Central Processor
        Family: Unknown
        Manufacturer: GenuineIntel
        ID: 54 06 05 00 FF FB AB 0F
        Version: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
        Voltage: 3.3 V
        External Clock: Unknown
        Max Speed: 30000 MHz
        Current Speed: 2100 MHz
        Status: Populated, Enabled
        Upgrade: ZIF Socket
        L1 Cache Handle: 0x0054
        L2 Cache Handle: 0x0094
        L3 Cache Handle: Not Provided
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified
        Core Count: 1
        Core Enabled: 1
        Characteristics:
                64-bit capable
                Execute Protection


processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 85
model name	: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
stepping	: 4
microcode	: 0x2006906
cpu MHz		: 2095.078
cache size	: 22528 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase smep arat md_clear flush_l1d arch_capabilities
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips	: 4190.15
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

Comment 3 Zdenek Pytela 2020-12-16 20:31:40 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/518

Comment 13 errata-xmlrpc 2021-05-18 14:58:20 UTC
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 (selinux-policy 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-2021:1639