SELinux is preventing /sbin/rsyslogd from using the 'sys_nice' capabilities. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that rsyslogd should have the sys_nice 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 rsyslogd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context system_u:system_r:syslogd_t:s0 Target Objects Unknown [ capability ] Source rsyslogd Source Path /sbin/rsyslogd Port <Inconnu> Host (removed) Source RPM Packages rsyslog-5.7.9-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-5.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38-1.fc15.x86_64 #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64 Alert Count 2 First Seen sam. 19 mars 2011 10:05:42 CET Last Seen sam. 19 mars 2011 10:05:42 CET Local ID a1847f0f-9a0d-43b5-932a-f999af7e1703 Raw Audit Messages type=AVC msg=audit(1300525542.8:66): avc: denied { sys_nice } for pid=2231 comm="rsyslogd" capability=23 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=capability type=AVC msg=audit(1300525542.8:66): avc: denied { setsched } for pid=2231 comm="rsyslogd" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=process type=SYSCALL msg=audit(1300525542.8:66): arch=x86_64 syscall=sched_setscheduler success=no exit=EACCES a0=8ba a1=0 a2=7f8ac98b3d38 a3=7f8ac98b39d0 items=0 ppid=1 pid=2231 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=rsyslogd exe=/sbin/rsyslogd subj=system_u:system_r:syslogd_t:s0 key=(null) Hash: rsyslogd,syslogd_t,syslogd_t,capability,sys_nice audit2allow #============= syslogd_t ============== allow syslogd_t self:capability sys_nice; allow syslogd_t self:process setsched; audit2allow -R #============= syslogd_t ============== allow syslogd_t self:capability sys_nice; allow syslogd_t self:process setsched;
*** Bug 689093 has been marked as a duplicate of this bug. ***
also affected by this issue. SELinux is preventing /sbin/rsyslogd from using the 'sys_nice' capabilities. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that rsyslogd should have the sys_nice 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 rsyslogd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context system_u:system_r:syslogd_t:s0 Target Objects Unknown [ capability ] Source rsyslogd Source Path /sbin/rsyslogd Port <Unknown> Host (removed) Source RPM Packages rsyslog-5.7.9-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-5.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux valhalla.workgroup 2.6.38-1.fc15.x86_64 #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64 Alert Count 11 First Seen Sat 19 Mar 2011 01:50:51 PM PDT Last Seen Sat 19 Mar 2011 05:05:42 PM PDT Local ID 16a92e92-1b89-45b1-a838-6b94033ea671 Raw Audit Messages type=AVC msg=audit(1300579542.605:17): avc: denied { sys_nice } for pid=1051 comm="rsyslogd" capability=23 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=capability type=AVC msg=audit(1300579542.605:17): avc: denied { setsched } for pid=1051 comm="rsyslogd" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=process type=SYSCALL msg=audit(1300579542.605:17): arch=x86_64 syscall=sched_setscheduler success=yes exit=0 a0=432 a1=0 a2=7f7536ff0d38 a3=7f7536ff09d0 items=0 ppid=1 pid=1051 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=rsyslogd exe=/sbin/rsyslogd subj=system_u:system_r:syslogd_t:s0 key=(null) Hash: rsyslogd,syslogd_t,syslogd_t,capability,sys_nice audit2allow #============= syslogd_t ============== allow syslogd_t self:capability sys_nice; allow syslogd_t self:process setsched; audit2allow -R #============= syslogd_t ============== allow syslogd_t self:capability sys_nice; allow syslogd_t self:process setsched; was able to restore ability to boot by setting selinux=0 at grub, then setting selinux to permissive in /etc/selinux/config.
Also affected by this bug when I updated this morning. Also had to set selinux to permissive to make the system usable. Noticed that NetworkManager.service also failed.
*** Bug 689121 has been marked as a duplicate of this bug. ***
*** Bug 689163 has been marked as a duplicate of this bug. ***
*** Bug 689136 has been marked as a duplicate of this bug. ***
So the new rsyslog-5.7.9 attempts these actions and if they are refused, it fails in a nasty way - it keeps running, but clients sending to /dev/log are hanging. Hence the various duplicate bugs about non-booting systems.
>allow syslogd_t self:capability sys_nice; >allow syslogd_t self:process setsched; Well, I do not think these AVC are problem. I believe the problem is /dev/log is mislabelled during boot and apps can talk with it (#689098, #689097,#689410).
Is udev running? # ps -eZ | grep udev
# ps -eZ | grep udev system_u:system_r:udev_t:s0-s0:c0.c1023 502 ? 00:00:00 udevd system_u:system_r:udev_t:s0-s0:c0.c1023 623 ? 00:00:00 udevd system_u:system_r:udev_t:s0-s0:c0.c1023 624 ? 00:00:00 udevd
# ls -lZ /dev/log srw-rw-rw-. root root system_u:object_r:devlog_t:s0 /dev/log # ps -eZ | grep udev system_u:system_r:udev_t:s0-s0:c0.c1023 533 ? 00:00:00 udevd system_u:system_r:udev_t:s0-s0:c0.c1023 1423 ? 00:00:00 udevd system_u:system_r:udev_t:s0-s0:c0.c1023 1622 ? 00:00:00 udevd
(In reply to comment #9) > >allow syslogd_t self:capability sys_nice; > >allow syslogd_t self:process setsched; > > Well, I do not think these AVC are problem. I believe they are a problem, because loading a custom policy module with just these two rules makes my problems within an F15 VM go away. Without the custom module, when I login via the virtual serial console and attempt to test the syslog, I get a hang: # strace logger hello ... socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1 connect(1, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0 sendto(1, "<13>Mar 21 15:20:32 root: hello", 31, MSG_NOSIGNAL, NULL, 0 ...and this call never finishes. With the custom module it completes fine. /dev/log is labelled devlog_t in both cases.
And with these rules you are not seeing other issues after boot # ausearch -m avc -ts recent I am updating my system to see if I have the same issue.
I'm using a custom policy module with the above rules, as well. But it doesn't seem to solve ALL errors concerning /dev/log: SELinux is preventing /sbin/unix_chkpwd from sendto access on the unix_dgram_socket /dev/log. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that unix_chkpwd should be allowed sendto access on the log unix_dgram_socket 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 unix_chkpwd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Quellkontext system_u:system_r:chkpwd_t:s0-s0:c0.c1023 Zielkontext system_u:system_r:init_t:s0 Zielobjekte /dev/log [ unix_dgram_socket ] Quelle unix_chkpwd Quellpfad /sbin/unix_chkpwd Port <Unbekannt> Host fedora.thinkpad RPM-Pakete der Quelle pam-1.1.3-8.fc15 RPM-Pakete des Ziels Richtlinien-RPM selinux-policy-3.9.16-5.fc15 SELinux aktiviert True Richtlinientyp targeted Enforcing-Modus Enforcing Rechnername fedora.thinkpad Plattform Linux fedora.thinkpad 2.6.38-1.fc15.x86_64 #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64 Anzahl der Alarme 2 Zuerst gesehen Mo 21 Mär 2011 13:10:00 CET Zuletzt gesehen Mo 21 Mär 2011 13:10:12 CET Lokale ID b2d9f849-facd-4974-bed2-d30d62b22466 Raw-Audit-Meldungen type=AVC msg=audit(1300709412.845:52): avc: denied { sendto } for pid=1537 comm="unix_chkpwd" path="/dev/log" scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=unix_dgram_socket type=SYSCALL msg=audit(1300709412.845:52): arch=x86_64 syscall=connect success=no exit=EACCES a0=3 a1=7f94dd2577c0 a2=6e a3=0 items=0 ppid=1534 pid=1537 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=unix_chkpwd exe=/sbin/unix_chkpwd subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) Hash: unix_chkpwd,chkpwd_t,init_t,unix_dgram_socket,sendto audit2allow #============= chkpwd_t ============== allow chkpwd_t init_t:unix_dgram_socket sendto; audit2allow -R #============= chkpwd_t ============== allow chkpwd_t init_t:unix_dgram_socket sendto;
Well, there are still some denials, but I have not noticed any ill effects due to them: time->Mon Mar 21 15:53:40 2011 type=PATH msg=audit(1300719220.743:31): item=1 name="/dev/.systemd/readahead" inode=14620 dev=00:05 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:device_t:s0 type=PATH msg=audit(1300719220.743:31): item=0 name="/dev/.systemd/" inode=6380 dev=00:05 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:device_t:s0 type=CWD msg=audit(1300719220.743:31): cwd="/" type=SYSCALL msg=audit(1300719220.743:31): arch=c000003e syscall=83 success=yes exit=0 a0=40504e a1=1ed a2=11 a3=3048283250 items=2 ppid=1 pid=958 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-notify" exe="/bin/systemd-notify" subj=system_u:system_r:systemd_notify_t:s0 key=(null) type=AVC msg=audit(1300719220.743:31): avc: denied { create } for pid=958 comm="systemd-notify" name="readahead" scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=dir type=AVC msg=audit(1300719220.743:31): avc: denied { add_name } for pid=958 comm="systemd-notify" name="readahead" scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=dir type=AVC msg=audit(1300719220.743:31): avc: denied { write } for pid=958 comm="systemd-notify" name=".systemd" dev=devtmpfs ino=6380 scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=dir ---- time->Mon Mar 21 15:53:40 2011 type=PATH msg=audit(1300719220.744:32): item=1 name="/dev/.systemd/readahead/done" inode=14621 dev=00:05 mode=0100664 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:device_t:s0 type=PATH msg=audit(1300719220.744:32): item=0 name="/dev/.systemd/readahead/" inode=14620 dev=00:05 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:device_t:s0 type=CWD msg=audit(1300719220.744:32): cwd="/" type=SYSCALL msg=audit(1300719220.744:32): arch=c000003e syscall=2 success=yes exit=3 a0=40506d a1=80141 a2=1b6 a3=3048283250 items=2 ppid=1 pid=958 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-notify" exe="/bin/systemd-notify" subj=system_u:system_r:systemd_notify_t:s0 key=(null) type=AVC msg=audit(1300719220.744:32): avc: denied { write open } for pid=958 comm="systemd-notify" name="done" dev=devtmpfs ino=14621 scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=file type=AVC msg=audit(1300719220.744:32): avc: denied { create } for pid=958 comm="systemd-notify" name="done" scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=file
the update has karma -4 and won't make it into dist-f15, so this is not actually blocking the Beta.
* Fri Mar 18 2011 Tomas Heinrich <theinric> 5.7.9-1 - integrate changes from Lennart Poettering to add support for systemd - add rsyslog-5.7.9-systemd.patch to tweak the upstream service file to honour configuration from /etc/sysconfig/rsyslog What are these changes?
*** Bug 689181 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > What are these changes? Here's a diff of the changes in the 5.7.9-1 package: http://pkgs.fedoraproject.org/gitweb/?p=rsyslog.git;a=commitdiff;h=df31784a31cd254b25d8674f3bdb6d5294d312ef
If systemd is going to impersonate syslog it needs to label its end of the socket correctly.
*** This bug has been marked as a duplicate of bug 689435 ***