Bug 1046470 - libselinux-2.2.1-4 doesn't respect SELINUX=disabled in /etc/selinux/config
Summary: libselinux-2.2.1-4 doesn't respect SELINUX=disabled in /etc/selinux/config
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libselinux
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1046450 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-25 14:45 UTC by TATEISHI Katsuyuki
Modified: 2014-08-06 22:32 UTC (History)
20 users (show)

Fixed In Version: libselinux-2.2.1-6.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-30 05:04:17 UTC


Attachments (Terms of Use)

Description TATEISHI Katsuyuki 2013-12-25 14:45:59 UTC
Description of problem:
SELinux goes permissive even if SELINUX=disabled in /etc/selinux/config

Version-Release number of selected component (if applicable):
libselinux-2.2.1-4.fc20

How reproducible:
Update libselinux to 2.2.1-4.fc20 with SELINUX=disabled in /etc/selinux/config 

Steps to Reproduce:
1. configure SELINUX=disabled in /etc/selinux/config
2. yum update libselinux (to 2.2.1-4.fc20)
3. reboot

Actual results:
# getenforce
Permissive
# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          disabled
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

Expected results:
# getenforce
Disabled
# sestatus
SELinux status:                 disabled

Additional info:
yum downgrade 'libselinux*' is a workaround. (i.e. 2.1.13-19.fc20 works for me)

I think the following hunk for src/load_policy.c in the libselinux-rhat.patch causes this problem:

@@ -410,7 +494,7 @@ int selinux_init_load_policy(int *enforce)
         * already mounted and selinuxmnt set above.
         */

-       if (seconfig == -1) {
+       if (*enforce == -1) {
                /* Runtime disable of SELinux. */
                rc = security_disable();
                if (rc == 0) {

It seems that *enforce is always 0 or positive number here because:

445         if (secmdline >= 0)
446                 *enforce = secmdline;
447         else if (seconfig >= 0)
448                 *enforce = seconfig;
449         else
450                 *enforce = 0;   /* unspecified or disabled */

is before the if (*enforce == -1) block.

A related post on Ask Fedora:
 https://ask.fedoraproject.org/question/37630

Comment 1 Nathan G. Grennan 2013-12-26 17:52:20 UTC
I am experiencing the same issue. I noticed when a auto-relabel happened out of the blue. The only way I have found to disable it is selinux=0 on the kernel command line.

Here is another Ask Fedora thread:
https://ask.fedoraproject.org/question/35512/

Comment 2 Adam Williamson 2013-12-27 02:44:49 UTC
Also someone on G+ frustrated about this. Since RH is supposed to be on vacation ATM so we can't rely on Dan fixing it quickly as he usually would, I'll see if I can find what went wrong and if it's something sufficiently simple for the QA monkey to fix...

Comment 3 Adam Williamson 2013-12-27 21:13:23 UTC
So this is a bit tricky to work out without dwalsh, because of how libselinux package works. libselinux-rhat.patch does lots of different things without explaining itself either in-line or via git commit messages.

So I went for a conservative approach. I checked upstream, and near as I can tell, nothing has changed here upstream for years, since 2008 really - I don't believe Dan's change to the patch was simply meant to adapt it to some upstream change, I think he was actually trying to change the behaviour of the patch.

I drew up a little test plan for selinux enablement and ran it against the F20 release libselinux (2.1.13-19), the "broken" one (2.2.1-4), and a new build I did (2.2.1-6) which drops the offending stanza from libselinux-rhat.patch.

As I expected, the result of this is that 2.2.1-4 behaves as described in this bug - disabling selinux via the config file never works - and 2.2.1-6 behaves identically to 2.1.13-19.

All three builds have some other issues, but the only case I could find where 2.2.1-4 is better than the other two builds is when you do this:

config file: SELINUX=disabled
cmdline: selinux=1 enforcing=0

I'd probably expect that to result in 'permissive', but with 2.1.13-19 and 2.2.1-6, it results in 'disabled'. With 2.2.1-4 it results in 'permissive'.

Still, that's a rather obscure case, and it seems like fixing that is not worth breaking all disablement via the config file. So I am going to send 2.2.1-6, with this change to rhat.patch reverted, to Rawhide and to F20 as a candidate update. Dan, when you're back, I can provide you with my full set of test results and explain the other cases which behaved other than expected, if you like. One obvious one is https://bugzilla.redhat.com/show_bug.cgi?id=907841 , which is broken for all three libselinux builds (i.e. 2.2.1-4 did not fix that bug, if it was intended to).

Comment 4 Adam Williamson 2013-12-27 21:31:59 UTC
btw, as a side note, the implementation of this whole area seems to leave a little to be desired. 

First, we have two ways of configuring SELinux enablement, which use a different approach. The config file considers it a single trinary setting: is "selinux" enforcing, permissive, or disabled? On the cmdline, it's instead implemented as two binary settings: is "selinux" on or off, and is "enforcing" on or off? Obviously, the expected behaviour in all possible cases here is rather less clear than if they both did it the same way.

In the code, we have three different variables zinging around in various files and functions - secmdline, seconfig, and *enforce. selinux_config.c's selinux_getenforcemode function is relatively clear - it sets *enforce to -1 for 'disabled', 0 for 'permissive', and 1 for 'enforcing', i.e. it's clearly backing the config file's trinary state. Fine. But that only covers the config file. load_policy.c does most of the actual heavy lifting here, and so far as I can tell, never clearly explains exactly what it's doing, or what the expected values for any of those three variables are. It's pretty hard for at least this idiot monkey to follow. I *think* the underlying bug here is that various bits of load_policy.c are confused about whether *enforce should be 0 or -1 if selinux is entirely disabled, but it's really difficult to be confident about this, for me anyway. I can't help feeling the code would be a lot simpler and less prone to borkage if both the cmdline and config file methods for configuring selinux's enablement state worked the same way.

Comment 5 Fedora Update System 2013-12-27 21:36:20 UTC
libselinux-2.2.1-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libselinux-2.2.1-6.fc20

Comment 6 Morten Stevens 2013-12-28 21:24:58 UTC
*** Bug 1046450 has been marked as a duplicate of this bug. ***

Comment 7 Morten Stevens 2013-12-28 21:27:27 UTC
libselinux-2.2.1-6.fc20 fixes it for me :)

Comment 8 Fedora Update System 2013-12-28 23:35:24 UTC
Package libselinux-2.2.1-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libselinux-2.2.1-6.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-24058/libselinux-2.2.1-6.fc20
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2013-12-30 05:04:17 UTC
libselinux-2.2.1-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Daniel Walsh 2014-01-02 17:43:51 UTC
Of course you could consider this a good time to try SELinux again.  And no the bug was not intentional.

Comment 11 Massimiliano 2014-03-27 22:54:54 UTC
Is this bug fixed? My environment is the following:

# rpm -q libselinux
libselinux-2.2.1-6.fc20.i686

# cat /etc/sysconfig/selinux 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 

# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.13.6-200.fc20.i686 root=UUID=e062105d-5d55-42dc-b1d1-f223771ba0a4 ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet

Comment 12 Kevin Fenzi 2014-03-28 02:08:37 UTC
Yes, it should be. 

What does: 

ls -l /etc/sysconfig/selinux 
and
cat /etc/selinux/config

give?

Comment 13 Massimiliano 2014-03-28 11:11:48 UTC
(In reply to Kevin Fenzi from comment #12)
> 
> ls -l /etc/sysconfig/selinux 
-rw-r--r--. 1 root root 548 24 mar 17.26 /etc/sysconfig/selinux

> cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

I'm figuring that I've modified the wrong file (I've used the sed -i command to do this).

But why there are two files?

Comment 14 Rex Dieter 2014-03-28 12:02:18 UTC
hint,

$ ls -l /etc/sysconfig/selinux 
lrwxrwxrwx. 1 root root 17 Sep  4  2013 /etc/sysconfig/selinux -> ../selinux/config

Comment 15 Massimiliano 2014-03-28 13:57:20 UTC
sed and symlink are not good friends:

$ echo hello > original.txt
$ ln -s original.txt symlinked.txt
$ ls -l
-rw-rw-r--   1 massi massi     6 28 mar 14.44 original.txt
lrwxrwxrwx   1 massi massi    12 28 mar 14.45 symlinked.txt -> original.txt
$ sed -i 's/hello/world/g' symlinked.txt 
$ ls -l
-rw-rw-r--   1 massi massi     6 28 mar 14.44 original.txt
-rw-rw-r--   1 massi massi     6 28 mar 14.46 symlinked.txt
$ cat original.txt                                                                                                                                                                 
hello
$ cat symlinked.txt                                                                                                                                                                
world

you need to add the --follow-symlinks options to make it work (maybe)

thanks

Comment 16 RIchard Gladman 2014-05-17 11:38:20 UTC
This is still badly broken.

I have disabled selinux and rebooted.

$ rpm -q libselinux
libselinux-2.2.1-6.fc20.x86_64

$ sestatus
SELinux status:                 disabled

$ cat /etc/sysconfig/selinux 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 

Yet when I try to install a piece of software to ~/bin I get

install: error: [Errno 13] Permission denied: '/etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin'

Comment 17 RIchard Gladman 2014-05-17 12:34:03 UTC
In order to fix this problem on my machine I did the following:
cd /etc/selinux/targeted/contexts/files/
sudo chmod 0744 *

This is because several file relating to the home directory were only readable by root thus giving the permission denied.

It's a home directory for Gods sake so why can't I install software to it?

And why is the file being looked at at all when selinux is supposedly disabled?

Fedora 20 if it helps.

Comment 18 Daniel Walsh 2014-05-19 13:52:25 UTC
This looks like it might be a bug in the coreutils package not respecting the is_selinux_enabled flag.

Comment 19 Daniel Walsh 2014-05-19 13:53:00 UTC
Although I don't know why those files would not be world readable.

Comment 20 Joshua Rosen 2014-07-03 13:08:21 UTC
I'm still seeing the bug. I have libselinux 2.2.1-6 installed. When I launch Altera's Quartus I get,

mkdir: /usr/local/tools/Quartus/linux64/liblzma.so.5: no version information available (required by /usr/lib64/libselinux.so.1)
cp: /usr/local/tools/Quartus/linux64/liblzma.so.5: no version information available (required by /usr/lib64/libselinux.so.1)

SELinux status:                 disabled

Comment 21 Daniel Walsh 2014-08-06 22:32:40 UTC
So the problem here is the files in /etc/selinux/contexts/files/file_context have wrong permissions, such that users can not read them?


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