Description of problem: SELinux is preventing acpid from 'open' accesses on the chr_file /dev/input/event26. ***** Plugin restorecon (90.5 confidence) suggests ************************ If you want to fix the label. /dev/input/event26 default label should be event_device_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /dev/input/event26 ***** Plugin device (9.50 confidence) suggests **************************** If you want to allow acpid to have open access on the event26 chr_file Then you need to change the label on /dev/input/event26 to a type of a similar device. Do # semanage fcontext -a -t SIMILAR_TYPE '/dev/input/event26' # restorecon -v '/dev/input/event26' ***** Plugin catchall (1.40 confidence) suggests ************************** If you believe that acpid should be allowed open access on the event26 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 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 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.24.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.14.16-300.fc27.x86_64 #1 SMP Wed Jan 31 19:24:27 UTC 2018 x86_64 x86_64 Alert Count 1 First Seen 2018-02-15 11:43:07 EST Last Seen 2018-02-15 11:43:07 EST Local ID d5edac89-8c07-4ead-ae0d-1984fc64b36d Raw Audit Messages type=AVC msg=audit(1518712987.749:15819): avc: denied { open } for pid=2057 comm="acpid" path="/dev/input/event26" dev="devtmpfs" ino=67046292 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 Hash: acpid,apmd_t,device_t,chr_file,open Version-Release number of selected component: selinux-policy-3.13.1-283.24.fc27.noarch Additional info: component: selinux-policy reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.3-300.fc27.x86_64 type: libreport
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.