Description of problem: Currently installed rpm: systemd-216-16.fc21.x86_64 SELinux is preventing systemctl from using the 'setrlimit' accesses on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemctl should be allowed setrlimit access on processes labeled logrotate_t 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: # grep systemctl /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:logrotate_t:s0-s0:c0.c1023 Target Context system_u:system_r:logrotate_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source systemctl Source Path systemctl Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM <Unknown> Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.17.8-300.fc21.x86_64 #1 SMP Thu Jan 8 23:32:49 UTC 2015 x86_64 x86_64 Alert Count 5 First Seen 2015-01-25 15:18:02 IST Last Seen 2015-01-25 15:18:02 IST Local ID bf99133d-bc45-4283-8491-e9bef8de751d Raw Audit Messages type=AVC msg=audit(1422179282.451:480): avc: denied { setrlimit } for pid=14976 comm="systemctl" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: systemctl,logrotate_t,logrotate_t,process,setrlimit Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.8-300.fc21.x86_64 type: libreport
Description of problem: system idle Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.8-300.fc21.x86_64 type: libreport
I too have this selinux alert plus three others that seem related: 1. sm-notify attempted write access on nlm_end_grace 2. console-kit-daemon.#prelink#.t5gd2(deleted) attempted write on /var/lib/dbus 3. systemctl attempted sys_resource capability detailed selinux reports for these three: 1. ---------------- SELinux is preventing /usr/sbin/sm-notify from write access on the file nlm_end_grace. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sm-notify should be allowed write access on the nlm_end_grace 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: # grep sm-notify /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:rpcd_t:s0 Target Context system_u:object_r:proc_t:s0 Target Objects nlm_end_grace [ file ] Source sm-notify Source Path /usr/sbin/sm-notify Port Host localhost.localdomain Source RPM Packages nfs-utils-1.3.1-5.0.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-103.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64 Alert Count 2 First Seen 2015-01-26 01:40:16 EST Last Seen 2015-01-27 11:27:18 EST Local ID 2ebdd364-92fa-4f4d-b8a1-4c7fef0b6cfb Raw Audit Messages type=AVC msg=audit(1422376038.990:347): avc: denied { write } for pid=1254 comm="sm-notify" name="nlm_end_grace" dev="proc" ino=4026532232 scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0 type=SYSCALL msg=audit(1422376038.990:347): arch=x86_64 syscall=open success=no exit=EACCES a0=7fd4858bd4f7 a1=1 a2=7fff9a404090 a3=0 items=0 ppid=1 pid=1254 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sm-notify exe=/usr/sbin/sm-notify subj=system_u:system_r:rpcd_t:s0 key=(null) Hash: sm-notify,rpcd_t,proc_t,file,write 2. ---------------- SELinux is preventing /usr/sbin/console-kit-daemon.#prelink#.t5Fgd2 (deleted) from write access on the directory /var/lib/dbus. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that console-kit-daemon.#prelink#.t5Fgd2 (deleted) should be allowed write access on the dbus directory 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: # grep console-kit-dae /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:consolekit_t:s0 Target Context system_u:object_r:system_dbusd_var_lib_t:s0 Target Objects /var/lib/dbus [ dir ] Source console-kit-dae Source Path /usr/sbin/console-kit-daemon.#prelink#.t5Fgd2 (deleted) Port Host localhost.localdomain Source RPM Packages ConsoleKit-0.4.5-9.fc21.x86_64 Target RPM Packages dbus-1.8.14-1.fc21.x86_64 Policy RPM selinux-policy-3.13.1-103.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64 Alert Count 16 First Seen 2014-12-19 09:16:36 EST Last Seen 2015-01-27 11:31:17 EST Local ID ab3fd868-75db-4d5a-b444-4a6e13a6a8b4 Raw Audit Messages type=AVC msg=audit(1422376277.288:444): avc: denied { write } for pid=1610 comm="console-kit-dae" name="dbus" dev="dm-0" ino=6029375 scontext=system_u:system_r:consolekit_t:s0 tcontext=system_u:object_r:system_dbusd_var_lib_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1422376277.288:444): arch=x86_64 syscall=open success=no exit=EACCES a0=1d3edd0 a1=c1 a2=1a4 a3=10 items=0 ppid=1 pid=1610 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=console-kit-dae exe=/usr/sbin/console-kit-daemon subj=system_u:system_r:consolekit_t:s0 key=(null) Hash: console-kit-dae,consolekit_t,system_dbusd_var_lib_t,dir,write 3. ------------------ SELinux is preventing /usr/bin/systemctl from using the sys_resource capability. ***** Plugin sys_resource (91.4 confidence) suggests ********************** If you do not want processes to require capabilities to use up all the system resources on your system; Then you need to diagnose why your system is running out of system resources and fix the problem. According to /usr/include/linux/capability.h, sys_resource is required to: /* Override resource limits. Set resource limits. */ /* Override quota limits. */ /* Override reserved space on ext2 filesystem */ /* Modify data journaling mode on ext3 filesystem (uses journaling resources) */ /* NOTE: ext2 honors fsuid when checking for resource overrides, so you can override using fsuid too */ /* Override size restrictions on IPC message queues */ /* Allow more than 64hz interrupts from the real-time clock */ /* Override max number of consoles on console allocation */ /* Override max number of keymaps */ /* Override resource limits. Set resource limits. */ /* Override quota limits. */ /* Override reserved space on ext2 filesystem */ /* Modify data journaling mode on ext3 filesystem (uses journaling resources) */ /* NOTE: ext2 honors fsuid when checking for resource overrides, so you can override using fsuid too */ /* Override size restrictions on IPC message queues */ /* Allow more than 64hz interrupts from the real-time clock */ /* Override max number of consoles on console allocation */ /* Override max number of keymaps */ /* Override resource limits. Set resource limits. */ /* Override quota limits. */ /* Override reserved space on ext2 filesystem */ /* Modify data journaling mode on ext3 filesystem (uses journaling resources) */ /* NOTE: ext2 honors fsuid when checking for resource overrides, so you can override using fsuid too */ /* Override size restrictions on IPC message queues */ /* Allow more than 64hz interrupts from the real-time clock */ /* Override max number of consoles on console allocation */ /* Override max number of keymaps */ Do fix the cause of the SYS_RESOURCE on your system. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that systemctl should have the sys_resource capability 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: # grep telinit /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:prelink_cron_system_t:s0-s0:c0.c 1023 Target Context system_u:system_r:prelink_cron_system_t:s0-s0:c0.c 1023 Target Objects Unknown [ capability ] Source telinit Source Path /usr/bin/systemctl Port Host localhost.localdomain Source RPM Packages systemd-216-17.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-103.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-01-28 03:15:12 EST Last Seen 2015-01-28 03:15:12 EST Local ID 1777c2b1-0226-4af1-a6f1-9113f6b0bad3 Raw Audit Messages type=AVC msg=audit(1422432912.618:2695): avc: denied { sys_resource } for pid=1579 comm="telinit" capability=24 scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tcontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=SYSCALL msg=audit(1422432912.618:2695): arch=x86_64 syscall=setrlimit success=no exit=EPERM a0=7 a1=7fffa85b3510 a2=0 a3=fffffffffffffffe items=0 ppid=24783 pid=1579 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=204 comm=telinit exe=/usr/bin/systemctl subj=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 key=(null) Hash: telinit,prelink_cron_system_t,prelink_cron_system_t,capability,sys_resource
Description of problem: Gnome locked the screen because I left it alone for a long time. When I unlocked the screen there was this. I really don’t know, what systemd and logrotate have in common. AFAIK is logrotate triggered by a cron.daily—whats the job of systemd in this case? Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.3-201.fc21.x86_64 type: libreport
Paul Please open a differnt bug for each avc. The original bug seems to be fixed in 3.13.1-105
Description of problem: It just occured. Version-Release number of selected component: selinux-policy-3.13.1-105.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.7-300.fc21.x86_64 type: libreport
Description of problem: Turning down the volume using the keyboard keys.... Version-Release number of selected component: selinux-policy-3.13.1-105.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.3-201.fc21.x86_64 type: libreport
Description of problem: Not Sure Version-Release number of selected component: selinux-policy-3.13.1-105.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.3-201.fc21.x86_64 type: libreport
Description of problem: Dunno how this one happened; I assume startup, might be a duplicate of # 1189382, or # 1184712. It's probably related. They all started happening one to two weeks ago. Version-Release number of selected component: selinux-policy-3.13.1-103.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.3-201.fc21.x86_64 type: libreport
selinux-policy-3.13.1-105.3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-105.3.fc21
Package selinux-policy-3.13.1-105.3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-105.3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1768/selinux-policy-3.13.1-105.3.fc21 then log in and leave karma (feedback).
Description of problem: nothing changed since installation Version-Release number of selected component: selinux-policy-3.13.1-105.1.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.3-201.fc21.x86_64 type: libreport
Description of problem: durante uma atualização: yum update -y && yum clean all && yum install fedup -y Additional info: reporter: libreport-2.3.0.37.gea76c hashmarkername: setroubleshoot kernel: 3.19.0-0.rc7.git0.1.vanilla.mainline.knurd.1.fc21.x86_64 type: libreport
selinux-policy-3.13.1-105.3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Still happening for me with selinux-policy-3.13.1-105.3.fc21. Any restorecon suggestion to retest?
Description of problem: This showed up after I setup tuned. Not sure if it is related to tuned profile I selected via tuned-gui. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.20.0-0.rc0.git6.2.fc23.x86_64 type: libreport
Description of problem: I don't know how it happened, it just popped up. I am not a techie person. I was just cheking my email on outlook.com using chrome browser and I got this SELinux alert. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
I still have the problem with selinux-policy-3.13.1-105.3.fc21.
Description of problem: after upgrade fedora 20 to 21. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Description of problem: Booted up the system, logged into Gnome desktop, started firefox, and saw this alert. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Description of problem: logrotate job running in cron.daily produces this error Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Description of problem: I did a yum-update then rebooted the VM Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Does anyone know why logrotate needs setrlimit?
Description of problem: Rebooting my computer does this. I think it came with system updated. I did not get this error on a clean installation of this distribution. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Logrotate does not use setrlimit. > If you believe that systemctl should be allowed setrlimit access on processes > labeled logrotate_t by default. According to this SELinux message from Comment 0, I presume that it's systemctl which uses setrlimit here. Logrotate can execute different programs like "gzip", "shred" or "/bin/sh" with custom shell script as part of logs handling. That depends on particular logrotate configuration files stored in /etc/logrotate.d. If it's caused by that, it would be useful to find out which config file from /etc/logrotate.d directory is causing this AVC. Just try to force the rotation with "logrotate -f /etc/logrotate.conf" and if you are able to reproduce it, try disabling config files in /etc/logrotate.d until it stops.
Did a "restorecon", then the "logrotate" as before. No re-occurrence. Also tried it on similiarly configured F21 system without restorecon. It reported the same error but above command did not evoke the error either? Will keep an eye on it on both systems.
The log rotations that invoke systemctl are httpd (/etc/logrotate.d/httpd) and possibly psacct (/etc/logrotate.d/psacct) which has a systemctl in an if statement. Note that /etc/logrotate.conf has an 'include /etc/logrotate.d' to drag in the .d directory. I know that httpd causes the error because those httpd logs were rotated last night and I got this error. The conf file shows that the systemctl is being invoked to reload the httpd service. Note that it's no good running logrotate manually to try to force the error. The logs have to satisfy the size/time criteria (as shown in the configs) and if they don't, no log rotation will happen. This does explain why the error seems to happen intermittently. The httpd logs get rotated weekly (global from /etc/logrotate.conf) but not if empty (specific in httpd).
Apache appears to use setrlimit for Virtual Hosts.
Daniel (or other person with SELinux knowledge), how is it supposed to work from SELinux point of view, when logrotate is restarting the daemon (httpd in this case) to let it reopen the log files? Logrotate in this case does fork() and: > execl("/bin/sh", "sh", "-c", script, "logrotate_script", logfn, NULL); where script="/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true". I don't think we should add more exceptions for logrotate itself, because in the postrotate script, admin can put basically anything.
Description of problem: related to logrotate Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Description of problem: i donot know Version-Release number of selected component: selinux-policy-3.13.1-105.1.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Description of problem: just ran my segfaulting binary Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
update do selinux-policy-3.13.1-105.5.fc21.noarch
Description of problem: I installed Logwatch Version-Release number of selected component: selinux-policy-3.13.1-105.1.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.6-200.fc21.x86_64 type: libreport
Description of problem: It appear at the xfce boot. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
*** This bug has been marked as a duplicate of bug 1184712 ***
Why should this be a duplicate of bug 1184712? This first occured for me with fc22 while 1184712 was reported to fc21. Also the problem still exists for me, while 1184712 is marked as closed (due to eol, though.)
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days