Bug 2170220 - DISA STIG with GUI in Red Hat Enterprise 9 causes the upower service to fail
Summary: DISA STIG with GUI in Red Hat Enterprise 9 causes the upower service to fail
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: systemd
Version: 9.0
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: systemd maint
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-15 22:14 UTC by mkielian@redhat.com
Modified: 2023-08-14 11:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
RHEL 9.0 DIS STIG GUI - upower broken (10.48 MB, application/x-xz)
2023-02-15 22:14 UTC, mkielian@redhat.com
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-148785 0 None None None 2023-02-15 22:16:01 UTC

Description mkielian@redhat.com 2023-02-15 22:14:32 UTC
Created attachment 1944429 [details]
RHEL 9.0 DIS STIG GUI - upower broken

Description of problem:

When applying Security Profile: [ DRAFT] DISA STIG with GUI for Red Hat Enterprise Linux 9

The upower service fails to start


Version-Release number of selected component (if applicable):
Red Hat Enterprise 9.0
Red Hat Enterprise 9.1


How reproducible: Always

Steps to Reproduce:


1. Install a fresh RHEL 9.x system

  Note: Tested on KVM 2 CPUs 2GB RAM
  
Create the following partitions: ( To comply with DISA STIG )

Setup with 20GB disk size 

Select "Custom", click Done

Use: Create partition button to create then add the following: "Click here to create them automatically"

/home   - 2GB
/tmp    - 1GB
/var    - 2GB
/var/log/      - 2GB
/var/log/audit - 1GB
/var/tmp       - 1GB

Remainder of space to / ( root partiton ) ~ 8GB



2. Select the Security profiles:

Use: [ DRAFT] DISA STIG with GUI for Red Hat Enterprise Linux 9

Click select Profiles button 

The bottom window should display the changes made.

Finish install an



3. Check the Status of upower service 

Upon logging in and running 

# systemctl status upower



Actual results:

Feb 14 13:23:43 localhost systemd[1]: Starting Daemon for power management...
 Subject: A start job for unit upower.service has begun execution
 Defined-By: systemd
 Support: https://access.redhat.com/support
 
 A start job for unit upower.service has begun execution.
 
 The job identifier is 317.
Feb 14 13:23:43 localhost systemd[1047]: upower.service: Failed to set up user namespacing: No space left on device
Feb 14 13:23:43 localhost systemd[1047]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: No space left on device
 Subject: Process /usr/libexec/upowerd could not be executed
 Defined-By: systemd
 Support: https://access.redhat.com/support
 
 The process /usr/libexec/upowerd could not be executed and failed.



Expected results:

upower service should be running and showing as active:

EXAMPLE: ( From RHEL 8 CSB Build ) 

$ systemctl status upower
- upower.service - Daemon for power management
   Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2023-02-05 18:41:53 MST; 1 weeks 2 days ago
     Docs: man:upowerd(8)
 Main PID: 5919 (upowerd)
    Tasks: 3 (limit: 202556)
   Memory: 2.3M
   CGroup: /system.slice/upower.service
           └─5919 /usr/libexec/upowerd





Additional info:

See attached sosreport from both RHEL 9.0 and RHEL 9.1 systems.

Comment 2 Bastien Nocera 2023-02-16 09:56:02 UTC
The security profile seems to disable user namespacing, which means systemd can't launch the service at all:
Feb 14 13:23:43 localhost systemd[1047]: upower.service: Failed to set up user namespacing: No space left on device

upower isn't even run.

user namespacing is used by systemd to provide upower with some sandboxing which protects the system from being made vulnerable if upower were to have bugs that weakened its security. This problem will also impact a lot of other daemons that also use systemd's sandboxing to minimise their attack surface.

Reassigning to systemd so they can figure out a better error message for this problem, and reassign to the security profile if needed.


Note You need to log in before you can comment on or make changes to this bug.