1

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

and

-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?

  • 1
    Does permissive mode show you the denials, usually you can work backwards when you're in permissive mode since it will show you what it would have done. – Steve Butler Apr 9 '15 at 15:06
  • Yep, I get the same denials in permissive mode but obviously it's no longer denying so I can SSH in as the user right now. I'm hoping I can work out how to make the denials go away in permissive so then I can set it back to enforcing – ydaetskcoR Apr 9 '15 at 15:50
6

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.

  • Thanks for this. I'll give this a shot over the weekend when we've got less developers reliant on the box being available. – ydaetskcoR Apr 10 '15 at 6:20
  • I've tried using restorecon but /home is still labelled as system_u:object_r:file_t:s0. I'm still not convinced that there's anything wrong with that label and more that the system context that sshd is using is wrong but I have no idea why it would be using the wrong context all of a sudden or even how to change it. – ydaetskcoR Apr 12 '15 at 22:07
  • That's still the wrong context. Are you sure your system is up to date? Not damaged? – Michael Hampton Apr 12 '15 at 22:15
  • You're right that the label was wrong. I checked again and a working /home had the label system_u:object_r:home_root_t:s0. I used chcon to force it to home_root_t and that worked straight away. Didn't need to unmount it (and couldn't seem to use chcon while it was unmounted either) so the secondary issue around / seems to have gone away too. Thanks again for the help. – ydaetskcoR Apr 12 '15 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.