Don't just disable SELinux!!

SELinux is a good thing, a *very* good thing for improving the security of your linux box.   Unfortunately most people seem to simply 'turn it off' rather than fix seemingly trivial problems, the following is an example.

On a new RHEL6.4 server install, SELinux is enabled by default in a 'enforcing' 'targeted' mode.  This means that the 'standard' daemons on the system are protected by a predefined security scheme configured by Redhat.    This is a good thing as even if there is a remote exploit for the daemon, the operating system can enforce access rules and limit or prevent anybody from actually doing anything with it.   Best of all, it's preconfigured, out of the box, ready to use.

Unfortunately it doesn't always work as expected and people turn it off.   In this instance I was informed that people couldn't use authorized_keys to login to the server.

Checking /var/log/audit/audit.log provided the following clue:

type=USER_AUTH msg=audit(1391466473.340:95114): user pid=60103 uid=0 auid=59418 ses=6119 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="l059418" exe="/usr/sbin/sshd" hostname=? addr=10.28.11.195 terminal=ssh res=failed'

  and in /var/log/secure

sshd[60103]: debug1: Could not open authorized keys '/home/user/.ssh/authorized_keys2': Permission denied

You could run the above audit error via audit2allow and import the policy, but it won't work as these rules already exist and then give up in disgust.  I'm not going to go into specifics for selinux as there are a heap of sites on the subject, the fix here was simply to fix the tags on the files so they have the correct security context.

$restorcon -Rv /home

And try again. 

Now, that wasn't difficult and was found with a single search of Google.  Better still spend a little time and learn about SELinux as I am, it will be worth the effort.