Bug 147615 - /etc/sysconfig/selinux is ignored
/etc/sysconfig/selinux is ignored
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-09 15:46 EST by Joe Cooper
Modified: 2015-01-04 17:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-10 09:01:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joe Cooper 2005-02-09 15:46:19 EST
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:
Comment 1 Joe Cooper 2005-02-09 15:57:09 EST
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.
Comment 2 Joe Cooper 2005-02-09 16:41:22 EST
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.
Comment 3 James Morris 2005-02-09 20:57:54 EST
Please provide the output of sestatus when this happens.
Comment 4 Joe Cooper 2005-02-09 21:38:29 EST
[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?
Comment 5 Joe Cooper 2005-02-09 21:51:26 EST
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
Comment 6 Joe Cooper 2005-02-09 22:28:28 EST
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!
Comment 7 Daniel Walsh 2005-02-10 09:01:26 EST
/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. 
Comment 8 Joe Cooper 2005-02-10 10:53:58 EST
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?

Note You need to log in before you can comment on or make changes to this bug.