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