In [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Users accounts usually get created and removed on most Development or Production servers. It is not uncommon to simply delete the users and yet not either delete or change the ownership of all files and directories associate with that user or user/group id. Some of the files might not be in the home directory of that user, so it is a good idea to search the whole file system for any files not owned by non-existent user or group. This is a big security issue, as an account might be created in the future with the same user or group id of the deleted account and end up having complete ownership of the files which don’t belong to them.

Solution – search ‘un-owned’ files and either change their ownership to ‘root:root’ or move them to some backup storage.


[root@danasmera ~]# declare -a no_user_files
[root@kauai ~]# for myfile in $(egrep '(ext2|ext3|ext4)' /etc/fstab | awk '{print $2}')
do
find $myfile -xdev \( -type f -o -type d \) -nouser -print
done

[root@danasmera ~]#for myfile in ${no_user_files[@]}; do chown  root:root $myfile;done

Follow similar steps for files/directories owned by non-existent domains.

[root@danasmera ~]# declare -a no_group_files
[root@danasmera ~]# for myfile in $(egrep '(ext2|ext3|ext4)' /etc/fstab | awk '{print $2}')
do
find $myfile -xdev \( -type f -o -type d \) -nogroup -print
done

[root@danasmera ~]#for myfile in ${no_group_files[@]}; do chown  root:root $myfile;done

For more information on hardening your Operating system or application, go to the Center for Internet Security website, an download the freely available Benchmarks. The Benchmarks are ‘scorable’, easy to follow steps by step instructions on how to secure you box.

Problem: every time a user logs in, they get “Could not chdir to home directory….Permission denied” error, although they can login to the system and change to their home directories without any problem.

Cause in this particular case: The system had a separate LVM partition for /home, and the partition crashed at one point, and was gone for good. I had to create a new LVM for the /home directory, and apparently SELinux doesn’t seem to like the security context as shown below.

-See the error below

[daniel@danasmera.com ~]$ ssh daniel@localhost
daniel@localhost's password:
Last login: Wed Dec 11 09:48:56 2013 from localhost.localdomain
Could not chdir to home directory /home/daniel: Permission denied

-No login or changing to home directory issue here.

[daniel@danasmera.com /]$ cd /home/daniel/
[daniel@danasmera.com ~]$ pwd
/home/daniel

-SELinux is enabled and in enforcing mode

[daniel@danasmera.com ~]$ sudo sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

-Let us set SELinux into permissive mode to see if that is the cause.

[root@danasmera.com ~]# setenforce 0
 
 
[root@danasmera.com ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

[daniel@danasmera.com ~]$ ssh daniel@localhost
daniel@localhost's password:
Last login: Wed Dec 11 09:50:11 2013 from localhost.localdomain

(No error message anymore!)..Now let us try to resolve the SELinux issue

-Let us display the security context for home

[root@danasmera.com ~]# ls -dZ /home
drwxr-xr-x. root root system_u:object_r:file_t:s0      /home

-Time to restore to default SELinux security context

[root@danasmera.com ~]# restorecon -v /home
restorecon reset /home context system_u:object_r:file_t:s0->system_u:object_r:home_root_t:s0

-Let us enable SELinux

[root@danasmera.com ~]# setenforce 1

-Error message disappears!

[daniel@danasmera.com ~]$ ssh daniel@localhost
daniel@localhost's password:
Last login: Wed Dec 11 09:52:11 2013 from localhost.localdomain