Description of problem: When trying to install over NFS from a server running current rawhide in enforcing mode, the install aborts because of NFS errors caused by the server. The precise timing varies. Version-Release number of selected component (if applicable): kernel-2.6.4-1.305 policy-1.10.1-2 nfs-utils-1.0.6-19.fc2 How reproducible: 100% Steps to Reproduce: 1. Probably should be sufficient to try copying an entire install tree from a rawhide NFS server (running in enforcing mode). Example tcpdump output of first error: 14:35:02.034154 IP 192.168.1.1.2049 > 192.168.1.7.490739511: reply ERR 20 read [|nfs] 192.168.1.1 is the server. I haven't tried 'setenforce 0; service nfs restart' yet, but will soon.
The failure doesn't happen after 'setenforce 0; service nfs restart'. So it happens in enforcing mode, but not in permissive mode.
If this is really a selinux problem (and it certainly looks that way since it works OK in permissive mode), I suspect it should be reported against policy and not nfs-utils. Therefore, I am adding Dan Walsh to the CC list.
This has nothing to do with the install and can be easier debugged with just doing a mount from another system. This is also more likely policy. OK, I did the following: 1. setenforcing 0 2. /etc/init.d/nfs start 3. setenforcing 1 4. from another system try to mount nfs volume on the system running nfs From that system's /var/log/messages, I get the following: Apr 16 08:38:37 chaos kernel: audit(1082119117.320:0): avc: granted { setenforce } for pid=18157 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Apr 16 08:38:58 chaos kernel: audit(1082119138.383:0): avc: denied { read } for pid=18129 comm=nfsd laddr=192.168.17.90 lport=2049 faddr=192.168.17.60 fport=619 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 16 08:38:58 chaos kernel: nfsd: recvfrom returned errno 13 Apr 16 08:38:58 chaos kernel: nfsd: terminating on error 13 Apr 16 08:39:07 chaos kernel: audit(1082119147.353:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:07 chaos kernel: audit(1082119147.554:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:07 chaos kernel: audit(1082119147.956:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:08 chaos kernel: audit(1082119148.760:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:10 chaos kernel: audit(1082119150.367:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:13 chaos kernel: audit(1082119153.583:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:20 chaos kernel: audit(1082119160.014:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:32 chaos kernel: audit(1082119172.876:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif
Note: 192.168.17.90 is the server 192.168.17.60 is the client
It looks like the system used for reporting this bug was messed up. Lots of files and processes have type unlabeled_t. If this still occurs then please add a comment with the AVC messages from a working system in enforcing mode.
Fixed in FC3.
(In reply to comment #6) > Fixed in FC3. Was this fixed properly for RHEL4 too? I am running RHEL 4 ES Update 1 with all errata applied and yet I have received these two messages from SELinux in enforcing mode with the targeted policy: audit(1125272367.492:0): avc: denied { rawip_recv } for pid=3869 comm=fping saddr=192.168.100.55 daddr=a.b.c.d netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif audit(1125272847.105:0): avc: denied { rawip_recv } for pid=1696 comm=named saddr=192.168.100.163 daddr=a.b.c.d netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Both those IP packets are valid, a.b.c.d is a public IP address of this server. I run fping to monitor reachability of some hosts in the internal network and this server acts as a nameserver for many clients in the internal network. Not being able to process those two packets did not hurt, but I am afraid that I could loose more important data in the future...
This looks like a labeling problem. Somehow your machine is mislabeled. To relabel touch /.autorelabel reboot Will clean it up.
(In reply to comment #8) > This looks like a labeling problem. Somehow your machine is mislabeled. To > relabel > touch /.autorelabel > reboot > Will clean it up. Are you sure that this will not clean up too much? I have quite a lot of preciously tuned stuff (httpd_sys_script_ro_t, httpd_sys_script_rw_t, etc.) and I would hate to loose it. If you could suggest what exactly should I relabel (using restorecon?) I would feel much safer.
I have a change that is going into initscripts to fix this. For now if you change the line in /etc/rc.sysinit to fixfiles restore instead of fixfiles -f -F relabel. It will preserve your customizables. Or execute fixfiles restore as root.
Being cautious, I have executed "fixfiles check" only, and nothing was shown. I really do not want to mess up my production server (it's RHEL4, not Fedora), so I have filed a support request at http://www.redhat.com/support (#672092) and I hope that I will get some help from there.
Ok rereading this, it looks like a problem, with an process running as unlabeled_t which should never happen. Have you rebooted the machine? Dan
Sure I have rebooted the machine. Last time 66 days ago. Running ps xaZ | grep unlabeled shows only onle line - grep unlabeled. Neither dovecot nor named have been restarted recently. Dovecot runs unconfined_t, named runs named_t.
Closing several old modified bugs