Moved /home to new disk, SELinux denying access to /home for sshd

ydaetskcoR asked:

Yesterday I added a drive to a Centos6 VM box, created a /home mount point on the drive and then moved a user (jenkins in this case) to it to free up space from the / mount point.

This seemed to work fine and permissions and labels all look right but earlier today I started seeing issues where I was unable to SSH on to the box as the jenkins user from any box. SSHing to the box as root and suing to jenkins worked fine. On top of that if I did a service sshd stop and then /usr/sbin/sshd I could then connect to the box directly as the jenkins user.

After lots of debugging I eventually spotted SELinux denials in /var/log/audit/audit.log like so:

type=AVC msg=audit(1428584552.564:187): avc:  denied  { search } for  pid=1798 comm="sshd" name="/" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=AVC msg=audit(1428584552.567:188): avc:  denied  { getattr } for  pid=1798 comm="sshd" path="/home" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

Setting SELinux to permissive then allowed me to reconnect as the jenkins user remotely.

I’m not too great with SELinux but after reading through (again) Gentoo’s tutorials on SELinux I read these errors as sshd trying to access both / and /home with a system context of system_u:system_r:sshd_t:s0. Instead these end points are labelled as system_u:object_r:file_t:s0 which is at least what the /home directory is labelled as (not too sure how to see the label for /).

To me those labels look right for those directories and I’m not too sure why it’s trying to look for an sshd_t label so far up the directory tree.

Running ls -laZ to get the important parts (.ssh folder and authorized_keys) gives me:

drwx------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 .ssh


-rw-------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 authorized_keys

Which looks the same as other boxes that I’m checking and they work fine.

What do I need to do to get SELinux to co-operate so I can go back to enforcing?

EDIT: I’ve tried umounting /home and using restorecon to try and relabel the directory thanks to Michael Hampton’s suggestion but that didn’t change the label on the directory and as mentioned above the system_u:object_r:file_t:s0 label for /home looks right when compared to other boxes that are running fine.

Is there a way I can change sshd’s system context when trying to access this directory?

My answer:

You aren’t looking at the right directories.

Your AVC denials are complaining specifically about the contexts on / and /home respectively, not on any file within them.

This makes me suspect that you have more than just those directory entries mislabeled.

This is how I would recover:

  1. Unmount /home. This is necessary because we want to restore the file context on the mount point in the parent filesystem as well as the file contexts within the child filesystem.
  2. Restore file contexts for the /home mount point.

    restorecon -v /home
  3. Remount /home.

  4. Restore file contexts for the entire system, just to be sure. This can be done one of two ways:

    • touch /.autorelabel and reboot. The system will be relabeled during startup.
    • restorecon -r -v / and reboot when finished. I usually use this method since it gives you a complete list of the file contexts that were changed.

Once you’ve relabeled and rebooted, you should be safe to return to SELinux enforcing.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.