Bug 1547139
Summary: | Spurious SELinux alerts: SELinux is preventing acpid from 'open' accesses on the chr_file /dev/input/event26. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Raman Gupta <rocketraman> |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 27 | CC: | aardvark, dwalsh, emailtoflorian, fathom, ingo, jskarvad, krinkodot22, lvrabec, mgrepl, plautrba, pmoore, rwithik, smitna |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:5b6ba3f90a6aa6bb52748a7b4162b836fc18753a79a14685a0df919523ba0bae; | ||
Fixed In Version: | selinux-policy-3.13.1-284.37.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-11-30 23:41:43 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
Raman Gupta
2018-02-20 15:25:15 UTC
FYI restorecon does nothing: # restorecon -Rv /dev/input <no output> I also note that event26 doesn't exist any more, so perhaps this is a timing issue? [root@edison ~]# ls -lZ /dev/input/event* crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 64 Feb 20 10:16 /dev/input/event0 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 65 Feb 20 10:16 /dev/input/event1 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 74 Feb 20 10:16 /dev/input/event10 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 75 Feb 20 10:16 /dev/input/event11 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 76 Feb 20 10:16 /dev/input/event12 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 77 Feb 20 10:16 /dev/input/event13 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 78 Feb 20 10:16 /dev/input/event14 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 79 Feb 20 10:16 /dev/input/event15 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 66 Feb 20 10:16 /dev/input/event2 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 67 Feb 20 10:16 /dev/input/event3 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 68 Feb 20 10:16 /dev/input/event4 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 69 Feb 20 10:16 /dev/input/event5 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 70 Feb 20 10:16 /dev/input/event6 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 71 Feb 20 10:16 /dev/input/event7 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 72 Feb 20 10:16 /dev/input/event8 crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 73 Feb 20 10:16 /dev/input/event9 Are you able to reproduce this bug? It looks like all event devices are labeled correctly on your system. Maybe timing issue. Please close this bug if you are not able to reproduce it. Thanks, Lukas. I can't reproduce it in the sense that I know and can trigger whatever causes it at will. But it happens at least once or twice every day so in that sense, yes, I can reproduce it. (In reply to Lukas Vrabec from comment #3) > Are you able to reproduce this bug? It looks like all event devices are > labeled correctly on your system. Ok, I think this is related to my Steelseries Arctis 7 USB headset -- I'm pretty sure that when I get the selinux alert, the USB headset device in PulseAudio disappears. It comes back again within a couple of seconds. Yup, I've confirmed the selinux alert at *exactly* the same moment that the USB audio device disappears from PulseAudio.
From the first post:
> Additional Information:
> Source Context system_u:system_r:apmd_t:s0
> Target Context system_u:object_r:device_t:s0
> Target Objects /dev/input/event26 [ chr_file ]
> Source acpid
> Source Path acpid
Why is the acpid target context device_t? Shouldn't it be event_device_t?
crw-rw----. 1 root input system_u:object_r:event_device_t:s0 13, 64 Feb 20 10:16 event0
Not really understanding what I'm doing here, I modified the policy from `ausearch -c 'acpid' --raw | audit2allow -M my-acpid` to change the target context from device_t to event_device_t and then loaded the custom module.
That did not fix the problem, but now I get a different selinux alert... from journalctl:
Feb 27 18:29:10 edison setroubleshoot[103042]: SELinux is preventing acpid from read access on the chr_file event258. For complete SELinux messages run: sealert -l c3be3ea9-1a7f-43b1-9e81-6a2a4e5efcf4
Feb 27 18:29:10 edison python3[103042]: SELinux is preventing acpid from read access on the chr_file event258.
***** Plugin device (91.4 confidence) suggests ****************************
If you want to allow acpid to have read access on the event258 chr_file
Then you need to change the label on event258 to a type of a similar device.
Do
# semanage fcontext -a -t SIMILAR_TYPE 'event258'
# restorecon -v 'event258'
***** Plugin catchall (9.59 confidence) suggests **************************
If you believe that acpid should be allowed read access on the event258 chr_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 'acpid' --raw | audit2allow -M my-acpid
# semodule -X 300 -i my-acpid.pp
and trying to get more information does not work at all:
# sealert -l c3be3ea9-1a7f-43b1-9e81-6a2a4e5efcf4
Error
query_alerts error (1003): id (c3be3ea9-1a7f-43b1-9e81-6a2a4e5efcf4) not found
*** Bug 1540323 has been marked as a duplicate of this bug. *** I put the apmd_t context into permissive mode and waited for the problem to happen again. It just did, so it seems that selinux is not actually "causing" the device to drop out -- the issue seems to be caused by something else and the audit messages are simply a result. In any case, here are the AVC's shown after permissive mode was enabled for apmd_t: type=AVC msg=audit(Wed Feb 28 11:33:32 2018.104:24268): avc: denied { read } for pid=2040 comm="acpid" name="event261" dev="devtmpfs" ino=404288081 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(Wed Feb 28 11:33:32 2018.104:24269): avc: denied { open } for pid=2040 comm="acpid" path="/dev/input/event261" dev="devtmpfs" ino=404288081 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(Wed Feb 28 11:33:32 2018.104:24270): avc: denied { ioctl } for pid=2040 comm="acpid" path="/dev/input/event261" dev="devtmpfs" ino=404288081 ioctlcmd=0x4520 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 Followup to my previous commment: while this does not appear to be an issue *caused* by selinux, selinux is still raising spurious alerts related to hardware on the system. I think this is something that should be fixed. *** Bug 1579373 has been marked as a duplicate of this bug. *** I can reproduce this reliably now, by unplugging my USB hub, and then replugging it. In my case this is somehow related to Bug 1579567 but it's the hub disconnect/reconnect that is relevant here. Description of problem: This alert was raised when my computer woke up from hibernation (which does work, to my delight!). If it makes a difference, I'm using the Nvidia graphics driver on Xorg. I'm not sure whether this access was a real violation or not, though, and everything does seem to be working fine... Version-Release number of selected component: selinux-policy-3.14.1-32.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.2-200.fc28.x86_64 type: libreport selinux-policy-3.13.1-284.37.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4bb4de2d86 selinux-policy-3.13.1-284.37.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-4bb4de2d86 selinux-policy-3.13.1-284.37.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. Description of problem: Occurs during transition to sleep power state. Version-Release number of selected component: selinux-policy-3.14.1-40.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.17.19-200.fc28.x86_64 type: libreport Description of problem: I don't know what triggered it this denial Version-Release number of selected component: selinux-policy-3.14.1-40.fc28.noarch Additional info: reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.18.5-200.fc28.x86_64 type: libreport Description of problem: Docked laptop with acpid running. Version-Release number of selected component: selinux-policy-3.13.1-284.37.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.18.12-100.fc27.x86_64 type: libreport selinux-policy-3.13.1-284.37.fc27.noarch So reopening. The problem happened when I docked laptop. It seems acpid is monitoring event devices for multimedia and system events (like brigthness+-, sleep key, media keys, etc.) especially needed for keyboards thus it needs read access. In my case event23 was USB mouse. commit 05e65862913dc214bb82e10ba7e78891023afbca (HEAD -> f27, origin/f27) Author: Lukas Vrabec <lvrabec> Date: Mon Aug 27 10:04:44 2018 +0200 Update dev_filetrans_all_named_dev() to allow create event22-30 character files with label event_device_t selinux-policy-3.13.1-284.38.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6c6faa135b selinux-policy-3.13.1-284.38.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6c6faa135b This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |