Description of problem: I'm seeing the AVC "avc: denied { read write }" messages detailed below when I install and start up luci/ricci on Xen guests. I have not been able to recreate the problem on a physical server. Version-Release number of selected component (if applicable): selinux-policy-2.4.6-35.el5 selinux-policy-targeted-2.4.6-35.el5 luci-0.8-30.el5 ricci-0.8-30.el5 How reproducible: 100% Steps to Reproduce: 1. Install ricci and luci and start the services Actual results: See below. Expected results: No errors. Additional info: [root@snausages ~]# uname -a Linux snausages.boston.devel.redhat.com 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux [root@snausages ~]# hostname snausages.boston.devel.redhat.com Feb 6 20:50:00 snausages kernel: SELinux: initialized (dev 0:19, type nfs), uses genfs_contexts Feb 6 20:50:25 snausages setroubleshoot: SELinux is preventing /usr/sbin/useradd (useradd_t) "read write" to faillog (var_log_t). For complete SELinux messages. run sealert -l 4e2f105e-c4a5-4764-95a6-3b36d6b5e6e6 Feb 6 20:53:32 snausages Installed: luci.x86_64 0.8-30.el5 Feb 6 20:53:33 snausages Installed: oddjob.x86_64 0.27-7 Feb 6 20:53:37 snausages Installed: modcluster.x86_64 0.8-27.el5 Feb 6 20:53:40 snausages setroubleshoot: SELinux is preventing /usr/sbin/useradd (useradd_t) "read write" to faillog (var_log_t). For complete SELinux messages. run sealert -l 4e2f105e-c4a5-4764-95a6-3b36d6b5e6e6 Feb 6 20:53:44 snausages Installed: ricci.x86_64 0.8-30.el5 Feb 6 20:53:54 snausages Installed: oddjob-libs.x86_64 0.27-7 Feb 6 20:55:27 snausages oddjobd: oddjobd startup succeeded Feb 6 20:55:27 snausages saslauthd[3876]: detach_tty : could not lock pid file /var/run/saslauthd/saslauthd.pid: Resource temporarily unavailable Feb 6 20:55:27 snausages saslauthd[3875]: detach_tty : Cannot start saslauthd Feb 6 20:55:27 snausages saslauthd[3875]: detach_tty : Another instance of saslauthd is currently running Feb 6 20:55:28 snausages ricci: startup succeeded Feb 6 20:55:41 snausages luci: startup succeeded Feb 6 20:55:41 snausages luci: Listening on port 8084; accessible using url https://snausages.boston.devel.redhat.com:8084 Feb 6 20:58:40 snausages scsi_id[3979]: scsi_id: unable to access parent device of '/block/xvda' Feb 6 20:58:43 snausages setroubleshoot: SELinux is preventing /usr/sbin/lvm (lvm_t) "write" to .cache (lvm_etc_t). For complete SELinux messages. run sealert -l 49e0308b-ccee-427d-929f-d180d1dbc4b6 [root@snausages ~]# rpm -qa | grep selinux-policy selinux-policy-2.4.6-35.el5 selinux-policy-targeted-2.4.6-35.el5 [root@snausages ~]# rpm -q luci ricci luci-0.8-30.el5 ricci-0.8-30.el5 [root@snausages ~]# cat /var/log/audit/audit.log | grep AVC type=AVC msg=audit(1170813023.441:121): avc: denied { read write } for pid=3695 comm="useradd" name="faillog" dev=dm-0 ino=163910 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1170813218.155:124): avc: denied { read write } for pid=3757 comm="useradd" name="faillog" dev=dm-0 ino=163910 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1170813518.095:128): avc: denied { write } for pid=3960 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813519.183:129): avc: denied { write } for pid=3964 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813519.251:130): avc: denied { write } for pid=3965 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813519.487:131): avc: denied { write } for pid=3966 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813520.087:132): avc: denied { write } for pid=3970 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813520.159:133): avc: denied { write } for pid=3971 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file type=AVC msg=audit(1170813520.279:134): avc: denied { write } for pid=3974 comm="lvm" name=".cache" dev=dm-0 ino=264301 scontext=root:system_r:lvm_t:s0 tcontext=root:object_r:lvm_etc_t:s0 tclass=file [root@snausages ~]#
Created attachment 147533 [details] Audit log
Note - the installation of luci and ricci do create user accounts and entries in /etc/passwd. luci:x:250:251::/var/lib/luci:/sbin/nologin ricci:x:251:252::/var/lib/ricci:/sbin/nologin
Cannot recreate the problem on a non-Xen system: Feb 7 08:39:36 tng3-5 Installed: luci.i386 0.8-30.el5 Feb 7 08:41:05 tng3-5 Installed: oddjob.i386 0.27-7 Feb 7 08:41:06 tng3-5 Installed: modcluster.i386 0.8-27.el5 Feb 7 08:41:12 tng3-5 Installed: oddjob-libs.i386 0.27-7 Feb 7 08:41:13 tng3-5 Installed: ricci.i386 0.8-30.el5 [root@tng3-5 ~]# rpm -q selinux-policy selinux-policy-targeted luci ricci selinux-policy-2.4.6-35.el5 selinux-policy-targeted-2.4.6-35.el5 luci-0.8-30.el5 ricci-0.8-30.el5 [root@tng3-5 ~]# uname -a Linux tng3-5 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686 i386 GNU/Linux
The problem is faillog is labeled incorrectly. restorecon /var/log/faillog will fix the problem. This should have been labeled correctly on install by pam. Any idea why its context is wrong?
Hmm. Well, one of the affected systems was a copy of the other, so whatever caused the issue on snausages would simply have been copied to the other system. No idea what might have caused this, though. This was a fresh install from the 20070118 nightly trees, which should be pretty close to production. From anaconda.log: 14:02:32 INFO : set fc of /var/log/btmp to system_u:object_r:faillog_t:s0 so it was set correctly on install. I haven't really done anything to that xen instance that would touch faillog. Something's really odd here.
Yeah, ignore that. That's /var/log/btmp.
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209646
Since this is caused by the bug detailed in bug 209646, I'm going to close this as a duplicate. *** This bug has been marked as a duplicate of 209646 ***