cPanel - Fix incorrect file/directory permissions

[NukeNick 23]

1. Run the following outside the preferred account’s public_html folder:

 

chown user:nobody /home/USER/public_html

Run the following inside the preferred account’s public_html folder:

 

chown -R user:user /home/USER/public_html

find -type f -exec chown user.user {} \;

find -type f -exec chmod 644 {} \;

find -type d -exec chmod 755 {} \;

Παράθεση

Where user, is your accounts name

 

[NickTheGreek 160]

Little tips:

• ρίχνετε καμιά ματιά και στο /homer/user/public_html αν ο PHP handler απαιτει nobody group και γυρίστε το ανάλογα
• το ίδιο ισχύει και για τα permissions, ειδικά για το public_html καλύτερα 750

https://documentation.cpanel.net/display/ALD/Configure+PHP+and+suEXEC

https://forums.cpanel.net/threads/switching-to-suphp.160421/

το παρακάτω ειναι απο offline website, το τράβηξα από Google Cache:

SysAdmin Tip - recursive chown can open your system for exploit

03 Jun 2010

A scenario system admins often encounter on shared hosting servers is the permission and ownership issue caused by using mod_php (otherwise known is PHP DSO). Files and directories created by mod_php will be owned by the user that Apache runs as, usually nobody or www-data. This presents a problem in at least two scenarios:

1. The user needs to perform some kind of management on the files; or
2. The sysadmin wants to convert to a more secure method of serving PHP content, usually mod_suphp where such ownership mis-match will cause 500 Internal Server errors.

One method often espoused when discussing how to address the ownership issue is to merely execute a recursive chown of the user’s home directory, like such:

 root@localhost # chown -R user:user /home/user

The recursive chown can open your system to exploitation. Let me demonstrate with a simple example.

Simple Example

Note: I strongly urge you to not perform this test on a production system. Use a throw away system, such as a VPS test system.

Note: the following will not work if the home directory for the user, or /etc is on a separate file system. Hard links may not cross device boundaries.

  
[root@squash ~]# ls -l /etc/shadow
-rw-------  1 root  root  0 Jun  3 07:30 /etc/shadow

[whoanel@squash ~]$ ln /etc/shadow public_html/favorite_book_list.txt
[whoanel@squash ~]$ ls -l public_html/favorite_book_list.txt
-rw------- 2 root root 905995 May 14 09:49 public_html/favorite_book_list.txt

[root@squash ~]# chown -R whoanel:whoanel /home/whoanel
[root@squash ~]# ls -l /etc/shadow
-rw-r--r-- 2 homer homer 0 Jun  3 07:35 /etc/shadow

The point to derive from the above is that the recursive chown will grant ownership of hard-linked files to the malicious user.

As noted before the example, the hard link vector will only work on files existing on the same partition/file system as the malicious account. Rather than targeting /etc/shadow such a user may try to link to other sensitive files, such as .my.cnf, wp-config.php and the like.

For this attack to properly work, the malicious user must accompany it with a social engineering vector. One can imagine a support request like:

“Hey, I'm trying to manage some files in my account but I keep getting errors. Could you help me?”

By sprinkling files throughout the directory via mod_php (thus increasing the cost of examining each file before changing ownership) the malicious user can mask his intent.

“Can’t I simply block the ability to create hard links?” If the user can run code at all on the system, then he can create a hard link.

The point I want to leave you with is this:

Don't blindly perform a recursive chown. Examine and perform a specific chown.