Bug 2144194

Summary: SELinux is preventing upsmon from 'create' accesses on the file upsmon.pid.
Product: [Fedora] Fedora Reporter: Trezamere <bugzilla-redhat>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 37CC: dwalsh, grepl.miroslav, lvrabec, mmalik, omosnacek, pizza, pkoncity, vmojzis, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---Flags: pizza: needinfo-
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:68a2299e644ee8b7da55bac7742520f6cabf8b37d5330d8cbbd9effec7a21744;
Fixed In Version: selinux-policy-37.18-1.fc37 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-19 06:10:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Trezamere 2022-11-19 19:03:20 UTC
Description of problem:
Upgrading to Fedora 37 and selinux started blocking nut-monitor
SELinux is preventing upsmon from 'create' accesses on the file upsmon.pid.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that upsmon should be allowed create access on the upsmon.pid file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'upsmon' --raw | audit2allow -M my-upsmon
# semodule -X 300 -i my-upsmon.pp

Additional Information:
Source Context                system_u:system_r:nut_upsmon_t:s0
Target Context                system_u:object_r:var_run_t:s0
Target Objects                upsmon.pid [ file ]
Source                        upsmon
Source Path                   upsmon
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-37.14-1.fc37.noarch
Local Policy RPM              selinux-policy-targeted-37.14-1.fc37.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 6.0.8-300.fc37.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022
                              x86_64 x86_64
Alert Count                   1
First Seen                    2022-11-19 11:59:02 MST
Last Seen                     2022-11-19 11:59:02 MST
Local ID                      dba84e29-1472-4c82-bdf2-d5e072333b31

Raw Audit Messages
type=AVC msg=audit(1668884342.141:388): avc:  denied  { create } for  pid=9536 comm="upsmon" name="upsmon.pid" scontext=system_u:system_r:nut_upsmon_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0


Hash: upsmon,nut_upsmon_t,var_run_t,file,create

Version-Release number of selected component:
selinux-policy-targeted-37.14-1.fc37.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.17.4
hashmarkername: setroubleshoot
kernel:         6.0.8-300.fc37.x86_64
type:           libreport

Comment 1 Solomon Peachy 2022-11-20 13:36:38 UTC
I got hit by this too.  If you don't configure the USB ups to run as root, then the daemon can't write the pidfile to /var/run, but if you configure it to run as root, it trips over selinux.

This is what autit2allow creates:

module my-usbhidups 1.0;

require {
        type nut_upsdrvctl_t;
        type var_run_t;
        class file { create getattr open read unlink write };
        class sock_file { create getattr setattr unlink };
        class capability { chown fsetid };
}

#============= nut_upsdrvctl_t ==============

#!!!! This avc is allowed in the current policy
allow nut_upsdrvctl_t self:capability { chown fsetid };

#!!!! This avc is allowed in the current policy
allow nut_upsdrvctl_t var_run_t:file { create getattr open read unlink write };

#!!!! This avc is allowed in the current policy
allow nut_upsdrvctl_t var_run_t:sock_file { create getattr setattr unlink };

Comment 2 Zdenek Pytela 2022-12-22 16:36:48 UTC
It seems nut started to use not only a directory in the /run filesystem, but also a file and a sock_file directly in /run, so I added appropriate rules. The following scratchbuild can be used:

https://github.com/fedora-selinux/selinux-policy/pull/1539
Checks -> Artifacts -> rpms.zip

For the other denials, please provide additional debugging info with full auditing enabled:

1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 3 Fedora Update System 2023-01-16 14:34:34 UTC
FEDORA-2023-e672cff7c6 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e672cff7c6

Comment 4 Fedora Update System 2023-01-17 02:40:11 UTC
FEDORA-2023-e672cff7c6 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e672cff7c6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e672cff7c6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2023-01-19 06:10:46 UTC
FEDORA-2023-e672cff7c6 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.