Description of problem: Setting SELINUX=permissive or disabled in /etc/sysconfig/selinux mostly works, but seems to leave it enabled for getattr (and possibly other file operations). Specifically, if Squid is configured to use a different cache_dir than default, it will fail to create directories or start. The following avc_denied message appears in dmesg: [root@localhost cache0]# dmesg audit(1107980971.927:0): avc: denied { getattr } for pid=4148 exe=/usr/sbin/squid path=/cache0 dev=hdc2 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:default_t tclass=dir And Squid's cache.log contains: 2005/02/09 14:22:48| /cache0: (13) Permission denied FATAL: Failed to verify one of the swap directories, Check cache.log for details. Run 'squid -z' to create swap directories if needed, or if running Squid for the first time. Squid Cache (Version 2.5.STABLE7): Terminated abnormally. suing to squid and creating and modifying files in /cache0 works fine...so I'm guessing just the getattr call is broken. But I'm not sure how to check that off-hand. Version-Release number of selected component (if applicable): kernel-2.6.10-1.760_FC3 selinux-policy-targeted-1.17.30-2.75 How reproducible: Always Steps to Reproduce: 1. Reboot into permissive or disabled mode 2. Configure Squid to use a directory other than /var/spool/squid for cache_dir (fails on both mount points and other directories) 3. squid -z 4. That's it. Actual results: No Squid directories created, and avc denied error appears in dmesg. Expected results: Squid directories created. I believe the avc denied messages should still appear in permissive mode, but Squid shouldn't get permission denied errors. Additional info:
Just to add to this thread. Adding the following to file_contexts and running restorecon on the /cache0 directory causes the above expected results (I just wanted to confirm that there are no other traditional Unix permissions issues, or anything else weird): # # Squid /cache directories # /cache.*(/.*)? system_u:object_r:squid_cache_t So, permissive is definitely not really permissive.
OK, more noise for this issue: After a reboot (with the contexts set as described above, which made it work), squid fails to start. The context is still set: [root@localhost /]# ls -Zd /cache0 drwxr-xr-x squid squid system_u:object_r:squid_cache_t /cache0 But squid -z fails and service squid start fails. The following (slightly different) avc denied error appears in dmesg: audit(1107984720.897:0): avc: denied { getattr } for pid=15694 exe=/usr/sbin/squid path=/cache0 dev=hdc2 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:nfs_t tclass=dir This has me thoroughly confused...I can't figure out where the nfs_t stuff is coming from. I guess getattr is given this context for some reason? I also can't figure out why this behavior doesn't present itself for /var/spool/squid, given that I've set /cache0 to the same context. Clearly I've done something wrong in the policy, but I don't understand what (and it doesn't change the fact that permissive doesn't permit getattr). BTW-I marked this as a regression because I saw a "permissive doesn't work" bug earlier, but this actually seems mostly unrelated to that one, so I've changed it to normal severity.
Please provide the output of sestatus when this happens.
[root@localhost ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 18 Policy from config file:targeted Policy booleans: allow_ypbind active dhcpd_disable_trans inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active mysqld_disable_trans inactive named_disable_trans inactive named_write_master_zonesinactive nscd_disable_trans inactive ntpd_disable_trans inactive portmap_disable_trans inactive postgresql_disable_transinactive snmpd_disable_trans inactive squid_disable_trans inactive syslogd_disable_trans inactive winbind_disable_trans inactive ypbind_disable_trans inactive OK, so I was wrong (and I had no idea sestatus existed, thanks for pointing it out). permissive mode is simply not taking effect. I've checked and double-checked to be sure there is no extraneous white-space in the /etc/sysconfig/selinux file. What am I doing wrong?
It may be worth adding that the boot log contains the following (which is what I was basing my belief that my box was booting into permissive mode despite indications to the contrary): Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode
OK, fun times. /etc/sysconfig/selinux is ignored completely. /etc/selinux/config has the desired impact, and permissive mode now works as advertised, including allowing all of the stuff I expected to work earlier. So the bug now is that there is an inactive /etc/sysconfig/selinux file, and an undocumented /etc/selinux/config that works. Quite a bit easier to understand this problem, anyway!
/etc/sysconfig/selinux was the location in FC2. Upgrading to FC3 should have created a symlink. Anyways /etc/selinux/config is documented in the FAQ in many places. man selinux also documents /etc/selinux/config The /etc/selinux/config configuration file controls whether SELinux is enabled or disabled, and if enabled, whether SELinux operates in per- missive mode or enforcing mode.
The Fedora Core 3 FAQ has the old location: http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825945 http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825945 The file /etc/sysconfig/selinux exists on a freshly installed FC3 system...I didn't create the file. That's very confusing, IMHO, since sysconfig is where I go looking for files of this sort. (It isn't owned by any package, so I'm not sure where it's coming from.) Should I refile a documentation issue?