What can go wrong if we disable selinux

Question

We inherited a bunch of used servers from another team. Some of them have SELinux enabled on it, some do not. Because of SELinux, we are having trouble setting up passwordless ssh, our webserver, etc. We found a work around on this stackexchange site, which is to run:

restorecon -R -v ~/.ssh

However, since we don't need SELinux running for what we do, it might be easier to turn it off than for us to remember to have everyone run the above cmd on whatever dir needs permissions.

Can we turn SELinux off w/o any repercussions down the road or is it better to just re-image the server? One thing to note; our IT group is really busy so re-imaging a server is not high on their list unless it's absolutely necessary (need a very good business case)...or someone bribes their boss with a bottle of scotch or whiskey.

UPDATE: Thanks for everyone's suggestion and advice. These servers are all going to be used as internal dev servers. There isn't going to be any outside access to these machines so security isn't a high concern to us. Our current servers that we are using all (to the best of my knowledge) do not have SELinux enabled. Some of the ones my manager just acquired do and those are the ones we're looking at disabling so everything in our cluster is uniform.

I answered a similar question on Android.se: How dangerous is the fact that SELinux is in “Permissive” mode? What should I be wary of?. The main difference between "Permissive" mode and disabling SELinux is that you will not get AVC log messages anymore and that SELinux will not keep files label up-to-date so you will need to relabel your files before enabling it again. — WhiteWinterWolf, Aug 04 '16 at 07:40
@scai That's actually a good question. As Sato Katsura points out, SELinux is hard to use effectively. A false sense of security is harmful to security. — Rhymoid, Aug 04 '16 at 12:05

score 16 · Answer 1 · answered Aug 03 '16 at 21:33

16

SELinux is a security feature of the operating system. It is designed to help protect some parts of the server from other parts.

For example, if you run a web server and have some "vulnerable" code that allows for an attacker to run arbitrary commands then SELinux can help mitigate this, by preventing your web server from accessing files it's not allowed to see.

Now you can disable SELinux and it shouldn't break anything. The server will keep on working as normal.

But you will have disabled one of the security features.

answered Aug 03 '16 at 21:33

Stephen Harris

44,540

14

SELinux works well only when configured properly. However, SELinux is so complicated that nobody has the time and / or knowledge to configure it properly, and thus it ends up either disabled, or as a perpetual pain in the rear for the admin. Yet you guys keep investing faith in it as a security feature. – Satō Katsura Aug 04 '16 at 07:14
3

I agree that selinux is a PITA to administer, yet it's still fair and entirely accurate to call it a security feature. for those who want or need to invest the time in learning and administering it (not me), it's invaluable - e.g. sysadmins for a large, high-profile web site aka an attractive target for script kiddies around the world. – cas Aug 04 '16 at 11:25
2

@SatoKatsura Simply because it's hard to configure or difficult to understand doesn't justify disabling a security mechanism. Provided that this security mechanism is actually needed which is not always easy to decide. – scai Aug 04 '16 at 12:21
@scai I didn't say it should (or shouldn't) be disabled. What I'm saying is, the underlying model of SELinux is flawed. Some people argue that all security mechanisms that can be disabled are flawed. – Satō Katsura Aug 04 '16 at 12:25
@SatoKatsura yes, that's why having passwords is completely and utterly pointless because they can be disabled (e.g. with pam or nss or just by having a blank password). BTW, i never claimed that you said selinux should be disabled. i was just disputing your assertion that it's not a real security feature. – cas Aug 05 '16 at 14:14
@cas You didn't. @ scai did. – Satō Katsura Aug 05 '16 at 14:48

score 9 · Answer 2 · edited Aug 04 '16 at 18:23

There are varying views of SELinux. In many cases, some applications do not play well with SELinux so that this decision is moot (Oracle is one example).
Generally, SELinux is a protecting mechanism to put yet another obstacle in the way of a bad guy wanting to subvert your system.

In my previous roles as Systems Administrator at large companies ... I have generally disabled SELinux. I did not have the time to track down all the SELinux errors on all the systems being used by users, developers, and managers.

Before disabling things, you might want to start by relabeling the files on the system back to what they should be. The easiest method I have found is entering the command:

 # /sbin/fixfiles onboot

OR

 # touch /.autorelabel

Then, reboot, and wait as it will take about the same amount of time for the system to verify and reset errant SELinux labels in the system. After that you might be ok as it fixes and corrects non-conforming SELinux labels which may have been modified prior to your attempting administration of the server.

However, if it doesn't, the system will not be harmed by NOT having SELinux in enforcing mode. It's just an extra layer of protection.

moot, not mute. But perfectly correct; not all systems need selinux. — phyrfox, Aug 04 '16 at 01:37
+1 for advising to try to globally relabel the files before disabling SELinux as a fallback. SELinux is meant to prevent unexpected software and users behavior. On systems where there is no well-defined expected behavior, SELinux may indeed cause more harm than good (OS-provided policies try to be as general as possible, but sometimes this is not enough). — WhiteWinterWolf, Aug 04 '16 at 13:16
Thank you! /sbin/fixfiles onboot worked for me on CentOS, not so with touch /.autorelabel. Running sealert -a /var/log/audit/audit.log shows 0 alerts now. @mdpc What's the difference between those two commands? — Joseph K., Aug 02 '19 at 11:29

sjsam · Answer 3 · 2016-08-04T12:01:22.313

4

Simply put, disabling mandatory access control(MAC) mechanisms like SELinux is not a good idea and may put you at a security-disadvantage if a bad guy successfully circumvent name-based access controls, implemented by Discretionary Access Control(DAC).

Were it me, I would do something like

semanage fcontext -a -t ssh_home_t ~/.ssh # Adding the policy
restorecon -R -v ~/.ssh # Applying the policy

to be extra sure about the type-label assigned recursively from ~/.ssh

edited Aug 04 '16 at 12:01

answered Aug 03 '16 at 21:34

sjsam

1,594
2
14
22

1

It's stylised "SELinux". Linux is not an acronym, and the "SE" part is an initialism. – Rhymoid Aug 04 '16 at 11:59
@Rhymoid : That's a good note indeed.. In fact what I wrote was accidental. – sjsam Aug 04 '16 at 12:02
It's not a good idea.... if the only thing you care about is security. But nobody uses a computer just so they can say "look how secure it is!"; they want to actually get stuff done! – Timmmm Nov 23 '23 at 09:40

score 2 · Answer 4 · answered Aug 04 '16 at 12:19

Generally speaking you shouldn't disable SELinux. There are tools that might help you understand what gone wrong. My favorite is sealert example usage:

sealert -a /var/log/audit/audit.log

OFC you can always set SELinux in permissive mode for debug, but keeping SELinux disabled or permissive is taught as serious security flaw by Red Hat.

What can go wrong if we disable selinux

4 Answers4