Bug 1547139 - Spurious SELinux alerts: SELinux is preventing acpid from 'open' accesses on the chr_file /dev/input/event26.
Summary: Spurious SELinux alerts: SELinux is preventing acpid from 'open' accesses on ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:5b6ba3f90a6aa6bb52748a7b416...
: 1540323 1579373 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-20 15:25 UTC by Raman Gupta
Modified: 2018-11-30 23:41 UTC (History)
13 users (show)

Fixed In Version: selinux-policy-3.13.1-284.37.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 23:41:43 UTC
Type: ---


Attachments (Terms of Use)

Description Raman Gupta 2018-02-20 15:25:15 UTC
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

Comment 1 Raman Gupta 2018-02-20 15:52:46 UTC
FYI restorecon does nothing:

# restorecon -Rv /dev/input
<no output>

Comment 2 Raman Gupta 2018-02-20 15:56:51 UTC
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

Comment 3 Lukas Vrabec 2018-02-26 15:01:37 UTC
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.

Comment 4 Raman Gupta 2018-02-26 16:59:22 UTC
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.

Comment 5 Raman Gupta 2018-02-27 22:56:34 UTC
(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.

Comment 6 Raman Gupta 2018-02-27 23:35:37 UTC
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

Comment 7 Raman Gupta 2018-02-28 16:35:19 UTC
*** Bug 1540323 has been marked as a duplicate of this bug. ***

Comment 8 Raman Gupta 2018-02-28 16:37:26 UTC
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

Comment 9 Raman Gupta 2018-05-17 21:52:12 UTC
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.

Comment 10 Lukas Vrabec 2018-05-22 11:34:07 UTC
*** Bug 1579373 has been marked as a duplicate of this bug. ***

Comment 11 Raman Gupta 2018-05-22 13:33:48 UTC
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.

Comment 12 krinkodot22 2018-06-25 00:56:28 UTC
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

Comment 13 Fedora Update System 2018-07-27 09:22:02 UTC
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

Comment 14 Fedora Update System 2018-07-27 15:38:45 UTC
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

Comment 15 Fedora Update System 2018-08-08 15:33:33 UTC
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.

Comment 16 smitna 2018-09-01 15:37:40 UTC
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

Comment 17 Flo H. 2018-09-09 19:20:41 UTC
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

Comment 18 Jaroslav Škarvada 2018-10-17 12:06:36 UTC
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

Comment 19 Jaroslav Škarvada 2018-10-17 12:16:35 UTC
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.

Comment 20 Lukas Vrabec 2018-11-04 12:48:28 UTC
commit 05e65862913dc214bb82e10ba7e78891023afbca (HEAD -> f27, origin/f27)
Author: Lukas Vrabec <lvrabec@redhat.com>
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

Comment 21 Fedora Update System 2018-11-06 13:49:33 UTC
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

Comment 22 Fedora Update System 2018-11-07 03:48:11 UTC
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

Comment 23 Ben Cotton 2018-11-27 13:37:48 UTC
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.

Comment 24 Ben Cotton 2018-11-30 23:41:43 UTC
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.


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