Hide Forgot
***** Plugin catchall (100. confidence) suggests ************************** If you believe that colord should be allowed read access on the hwdb.bin 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 'colord' --raw | audit2allow -M my-colord # semodule -i my-colord.pp Additional Information: Source Context system_u:system_r:colord_t:s0 Target Context system_u:object_r:systemd_hwdb_etc_t:s0 Target Objects /etc/udev/hwdb.bin [ file ] Source colord Source Path /usr/libexec/colord Port <Unknown> Host REDACTED Source RPM Packages colord-1.2.7-2.el7.x86_64 Target RPM Packages systemd-219-27.el7.x86_64 Policy RPM selinux-policy-3.13.1-96.el7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name REDACTED Platform Linux REDACTED 3.10.0-500.el7.x86_64 #1 SMP Tue Aug 30 18:58:04 EDT 2016 x86_64 x86_64 Alert Count 4 First Seen 2016-08-26 07:59:58 CEST Last Seen 2016-09-05 08:20:09 CEST Local ID 8d9de012-147d-4642-bf87-c860b47eff24 Raw Audit Messages type=AVC msg=audit(1473056409.994:170): avc: denied { read } for pid=1704 comm="colord" name="hwdb.bin" dev="sda3" ino=3408740 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:object_r:systemd_hwdb_etc_t:s0 tclass=file type=SYSCALL msg=audit(1473056409.994:170): arch=x86_64 syscall=open success=no exit=EACCES a0=7f430c0e02fb a1=80000 a2=1b6 a3=24 items=0 ppid=1 pid=1704 auid=4294967295 uid=996 gid=994 euid=996 suid=996 fsuid=996 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0 key=(null) Hash: colord,colord_t,systemd_hwdb_etc_t,file,read
Could you switch the colord_t domain to permissive and collect all SELinux denials causes by colord? # semanage permissive -a colord_t For switching the colord_t domain back to enforcing, please use following command: # semanage permissive -d colord_t
Sure, I've executed the recommended command. There apparently are no other denials, though, because this is the only one announced by SELinux troubleshooter. I might add that the denial appeared in sealert right after I logged in to Gnome. I didn't do anything in the color management screen in Gnome settings, and if I do open the screen and click around, no new (permitted or not) denial is logged. Is there anything else I could do to help scope this issue?
Following command should find all today's SELinux denials: # ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today
Created attachment 1197808 [details] List of today's denials OK, here they are. Those involving aaargh-0.7.1-py2.7.egg probably won't appear anymore and aren't bugs. sealert recommended restoring the context of that directory, and I did that.
*** Bug 1381579 has been marked as a duplicate of this bug. ***
*** Bug 1398030 has been marked as a duplicate of this bug. ***
*** Bug 1460480 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1861