Why are 644 and 755 unix permissions ideal for files/directories in public folders?

[dakman]

I've been searching around and I still can't figure out why most scripts and developers recommend that the ideal unix permissions for public_html/other public files and folders are ... 644 permissions for files and 755 permissions for folders...

The reason why I'm confused that scripts and others recommend this is if you install a script in a shared hosting environment, even if you're using SuPHP or open_basedir or other security practices, someone on that server could still possibly "view" your files which could include database config files and other files that you wouldn't want someone to read/access.

It would make sense that files should be 640 and folders 750 so that the world user (and executed processes/scripts PHP, CGI, PERL, SSH etc) can NOT access your files/folders.

So why is this not recommended as it seems to be the more secure permission set for files/directories? Is 644 or 755 a security risk?

.... Also, although my original question is for files/directories in "public" directories.. technically my question is for any file/directory thats owned by a user/usergroup that shouldn't be accessible by the public.. Why would you want to make files/directories world readable at all?

For instance with our cPanel install, when we provision accounts in WHM, it creates .htaccess files with 644 permissions .. well why would it do this if .htaccess shouldnt be read by other users .. Shouldn't it have 640 or 440 permissions? Is 644 a security risk so why would cPanel .htaccess to this? Even with SuPHP default/recommended permissions appear to be 644/755 which I'm confused why?

[cpanelkenneth]

if Apache needs to read the file, or access the directory, then the permissions need be 0644 or 0755. If the file or directory is set to the Apache group ( nobody ) then that won't apply.

[sparek-3]

644 means that files are readable and writeable by the owner of the file and readable by users in the group owner of that file and readable by everyone else.

755 is the same thing, it just has the execute bit set for everyone. The execute bit is needed to be able to change into the directory. This is why directories are commonly set to 755.

Regular HTML files need to be viewable by the Apache user (user nobody on cPanel servers). Since this user is typically not in the group of the ownership of the file (and if it were, and in a shared hosting environment every user would have to be in this group, which kind of defeats the purpose of limiting to 640 or 750) the world section of the permissions needs to be set to readable.

Now in a suPHP environment, PHP files can just as easily be set to 600. This is because the PHP files are read by the web server as the username specified in the virtualhost section in Apache. In a non-suPHP environment though, PHP files are still read by the apache user and therefor would require a world-readable bit. Again, this would only apply to PHP parsed files, not regular .html or .htm files.

Most scripts have separate config files which include login information. And yes, for those files I would recommend that they are set to a permission setting of 600 to prevent others from reading it. Other PHP files could also be set to 600, but you're really not saving yourself anything if the PHP files have no critical information included. For example, setting the permissions to Wordpress's main index.php file to 600 kind of defeats the point because someone can just download Wordpress from Wordpress's site and read the index.php file.

suPHP and PHP as CGI really are not a standard. PHP developers cannot recommend to set the permissions on the files to 600 because if PHP is running as a DSO module on the server, then using 600 permissions will not work. This is one reason why I think suPHP and PHP as CGI should be standard on any shared hosting server, but the owner of that server or the owner of the account on that server needs to realize that it is important to set the permissions on these config files to 600 and ignore the recommendations in the software's specifications.

[dakman]

sparek-3, Thanks for your reply...

Yea I agree with you and that's what I mean... It seems like this is a huge security issue and more than likely every shared host is affected... I was totally assuming that cPanel updates were already taking this into consideration but I was wrong..

I can't believe SuPHP isn't a requirement for WHM as the main reason someone would use WHM would be for shared hosting/reselling...

Even .htaccess files (which could have path info to .htpasswd files and other information) .. these are automically set as 644 by cPanel upon account creation... which I think is a security risk..

What I don't get is why in a shared env cPanel would let any file (.dat, .cgi, .pl, .php etc whatever file) to have world-readable access in the /home/ directory... Wouldn't cPanel and Apache have taken this into consideration now with the zillions of shared hosts? I know there's php open_basedir but there are many other file types and situations. Bottomline whats in one home dir shouldnt be accesible by anyone outside of the homedir/ at least in the cPanel environment which most of the time is a "shared" environment.. Why wouldn't this have been thought of previously?

There are of probably millions of shared hosts where Word Press, Joomla, etc config files are set as 644 or higher allowing possible access to their files by other users in other home directories... I don't understand cPanel doesn't "auto" lock those files from world-readable access and work with apache to create a "mod_sharedhost" or something that will fully isolate a homedir (its requested scripts, processes, files etc) to the homedir's user/usergroup...

Bottomline... you can't always rely on your users to "chmod" properly ... there should be options in WHM and Apache for full isolation of a user's files regardless of your users sloppy permission settings...

[cpanelkenneth]

It's up to the server administrator to secure a server according to the particular needs of the business or clients.

[sparek-3]

Well, you can't really blame cPanel here. Their focus isn't as a security auditing system, but as a means to access and administrate a website/email/database, etc.

The main issue with PHP files, is that PHP developers (Wordpress, Joomla, phpBB, etc) cannot know if the server you are installing the script on is using suPHP or using DSO PHP. Because of that they have to assume the situation that leads to the greatest workability, that means having higher permissions.

There is no way for cPanel or really any server administrator to know that a user on their server has installed Wordpress and did not lock down the permissions on the config file. I listed about 3 scripts in the above paragraph, but there is way more than 3 scripts available that can be installed on a user's account, 1000's of scripts exist. How do you find and lock down the permissions for every single one of those scripts? How do you know to lock down permissions for custom created scripts? End-user accountability has to start somewhere. End-users have to know what scripts they have installed and how to lock down the permissions on those scripts.

Regarding .htaccess files, there's just no way around this. Apache has to have read access to the file. Most of the information in the .htaccess file is not sensitive for privacy matters. In regards to Directory Protection with htpasswd files in the .htaccess file, by default cPanel places these htpasswd files outside the DocumentRoot, meaning that only other accounts on the same server would conceivably have read access to these files. The information stored in these files is encrypted and not easily broken unless you are using a weak password, in which case this begs the question of why the user was using such a weak password?

Ultimately if security is a paramount issue for you, then each account needs to be on its own dedicated server. The reason shared hosting is inexpensive when compared to dedicated hosting is because certain sacrifices have to be made. It is just not possible to have a completely secure system (with anything, not just webhosting) in a shared environment.

[dakman]

I agree with you... It might be almost impossible and almost annoying to have WHM fully help lock down a server and there is so much security a shared env can have, however, this is basic security I'm talking about here... one persons stuff shouldn't be visible by another person.. bottomline... think of a hotel ... a "shared environment"... one guest can't just go in someone else's room easily. The hotel owner ensures that guests rooms are not available for other guests to access, this is a reasonable policy and the hotel owner would be in deep s**t if other guests had access to other guests rooms....

This is why anything with world-readable/writable/executable permissions completely shouldn't even be possible in any home dir no matter how responsible/irresponsible a user is. The whole point and reason WHM or any panel uses the /home dir is to separate that users files/mail/etc from another users.. So, logically, there's no reason why a script would need access to anothers home dir/ knowing its a shared environment and on a shared hosting env it shouldn't be allowed to go outside of that users /home/ dir ...

So I think the WHM admin should be able to enable a "mod_shared host" or something that will get rid of global permissions eg there will only be 64 not 644 for any file in /home/<user>/... If someone chmods something to anything in Y ... XXY ... Y is completely ignored and set to 0...

If the server admin wants to override such settings, there could be an override feature but by default, just as PHP open_basedir restrictions settings in WHM work for PHP, the same should go for all files/scripts part of a home dir (any extension), under normal shared hosting shouldn't be accessible by any method (FTP, SSH, any apache module/process - CGI, Java etc) regardless of DSO, SuPHP...

Back to the topic of responsibility... The problem is under most large shared hosts (many of which use DSO still), its pretty much impossible to even allow a responsible user to lock down their files as Apache requires at least readable permissions on files... this is the beauty of SuPHP but it only applies to PHP... I think protecting just PHP files is just like saying we'll protect certain doors in the hotel room doors but not others... How could large shared hosting providers sleep at night knowing that they are not protecting everything in their users home directories? This should be a simple and reasonable request that a user would expect when signing up for Shared hosting...

Shared hosting shouldn't be like open kindergarten cubbies with a curtain protecting the contents, instead, anyone signing up for shared hosting would expect their host to at least have a high school locker with a pad lock ....

Or am I missing something? Is there a solution already for this reasonable security practice of protecting users from each other user? How do the big shared hosting operations have a large shared environment with hundreds of users on a box NOT allowing others to view/access other peoples stuff?

[cPanelDon]

Or am I missing something? Is there a solution already for this reasonable security practice of protecting users from each other user? How do the big shared hosting operations have a large shared environment with hundreds of users on a box NOT allowing others to view/access other peoples stuff?

A simple answer is to use both SuPHP and SuExec in addition to your normal security-related provisioning. To reiterate, the decision to use a specific configuration is entirely the responsibility of the systems administrator; many systems are not used in a shared environment and so forcing a more complex and specific configuration by default may not work best for everyone.

If in need of clarification on how to do this, please reference the following post that contains (in addition to other information) verbose detail on how to switch from DSO to SuPHP:
cPanel Forums - View Single Post - PHP mail() and bandwidth logging

[dakman]

Thanks for your reply Don,

I understand many are not in a shared environment and I can respect that WHM won't make those changes but specifically for our environment how would SuPHP/Suexec and normal security provisioning alone be enough to properly avoid User A from being able to view User B's files...

Is there a way to make open_basedir apply for any file/folder in a users home directory so that User A's files BOTH php and non-php, no matter what permissions are set, can't be viewed by User B?

[cPanelDon]

Is there a way to make open_basedir apply for any file/folder in a users home directory so that User A's files BOTH php and non-php, no matter what permissions are set, can't be viewed by User B?

I suggest using a combination of a hardened PHP configuration, via careful analysis and tweaking of each PHP option while referring to official PHP documentation and Internet searches, and PHP Suhosin, installed via EasyApache, to further restrict abusive activity stemming from the use of PHP. Please note that to take full advantage of PHP Suhosin it is necessary to manually insert its configuration directives into the main (server-wide) PHP configuration (php.ini) file after having it installed; documentation for this purpose may be obtained at the official Suhosin web site (as noted further below) and, if needed, additional verbose details are also contained in the downloadable source code of Suhosin. To clarify and reiterate, by default Suhosin uses stock values for its PHP configuration; however, you may freely customize these to your preferences by defining new values within your system PHP configuration (php.ini) file at the following path:
/usr/local/lib/php.ini

For additional variables and to configure PHP Suhosin, as it is a third-party product, I recommend to refer to and thoroughly review the official documentation at its main web site here:
Hardened-PHP Project - PHP Security - Suhosin
Hardened-PHP Project - PHP Security - Configuration
Hardened-PHP Project - PHP Security - Troubleshooting
Hardened-PHP Project - PHP Security - Frequently Asked Questions
Hardened-PHP Project Forum

If using both SuPHP and SuExec and if there is still a problem with users accessing the files and directory listings of other accounts, the system administrator must ensure that correct user and group ownerships are set on the files and directories within the home directory structure of each user account; additionally, either the system administrator or the user must ensure that proper (chmod) access permissions are set for the files and directories contained within the respective home directories. There is always the chance of human error, including if a user either intentionally or inadvertently uses an access permissions (chmod) value that may potentially allow anyone to read a specific file or directory listing if the parent directory permissions also allow it, but if the permissions of the parent directory do not allow it then data within may not be at as great of risk.

Without having direct access to the system to know the exact circumstances involved it is difficult to determine what precise measures will help in your specific situation; if assistance is needed with OS hardening, file system security, and or PHP security configurations I recommend referring to your dedicated systems administration or server management team for advice relevant to the applicable scenario involved. If additional assistance is needed with systems administration responsibilities and or server management tasks I recommend the following advertising forums as a starting point to locate appropriate third-party services:
Server Management and Server Repair - cPanel Forums

[dakman]

Thanks Don...

Thanks for the links I'll definitely check.. but about this...

but if the permissions of the parent directory do not allow it then data within may not be at as great of risk.

Here's an example why I'm concerned:

1. logged in via SSH to one of our accounts...

2. Confirmed .htaccess is 644 and owned by the proper user.. home directory permissions were set to 750 by cPanel.. cPanel provisioned .htaccess as 644

3. Logged into another account on the same server via SSH

4. cat /home/user/path/to/.htaccess

5. Spits out all of .htaccess

That is why 644 is completely insecure for files it seems...

Yea maybe I'm "bin/bash'ed" SSH user.. and I know I could jail/block SSH access, use SuPHP set PHP files to 640 but what about other files with config or db connections XML etc that aren't PHP files...

Or what about other non-php (CGI, Java who knows what) scripts that are uploaded to a server that are able to view other users "world readable" files (since they are set as 644) that possibly pipe them into an email etc?

Is their a realistic way to control such security breaches from occurring in shared environment?

[dakman]

Example user could upload and somehow execute a cgi, pl, php, Java, C or even some type of bash script with "cat" like functions that spit out contents of other users files into their accounts...

In a shared environment where we have many different users with all different permissions set (depending on their level of responsibility/knowledge), I see this could be a big security risk...

That's why I never understood why 644/755 is deemed as "safe" when 777 is always a big no no ... when even 644 can have almost the same security risk but with the ability for other hosting accounts to view others stuff..

So its like how can an administrator of a server prevent this? What do the large scale shared hosting providers do to provide ultimate security from User A being able to see User B's stuff?

[sparek-3]

Would using the Apache perchild MPM work for this?

perchild - Apache HTTP Server

I really think what you are wanting is beyond the scope of shared hosting. A shared host is always going to have SOME insecurities, if for no other reason that memory and process usage is shared among many different users. You can try to lock it down as much as you can, but the truth is, if you want an account to be isolated from other accounts, it will have to be on its own dedicated server. And then maybe from a network standpoint, you'll want it in a datacenter with no other servers.

You can't have these restricted file permissions on a shared host. Apache HAS to be able to read files, such as the .htaccess file and HTML files. Since apache HAS to read these files, and ALL of the accounts on the hosting server are served using apache, then apache HAS to have read access for ALL of these files.

I think the question you have to ask, is what do you want to hide from these files?

What is in the .htaccess file that is so confidential that other users shouldn't be reading it?

What are in HTML files that other users shouldn't be reading? (besides the fact that HTML is plainly viewable in a web browser).

PHP configuration files that include database logins and other login information, I can see. But this is saved with suPHP and using 600 permissions.

The same is true for CGI and perl scripts, suexec protects these files which might contain login information.

Splitting the Apache child processes up into individual users would be the only hope of accomplishing what you are wanting to do on a shared host (and even this only handles the Apache/web service aspect). However I would suspect that implementing this would consume more resources versus the prefork and worker MPMs.

[dakman]

Sparek-3... Yea I think you're right. I think Shared hosting has its limits. The problem is how do shared hosting companies using WHM/or any other panel for that matter, provide the best security possible for its users.. Right now, we are using DSO but I think we'll switch and do the following ... I guess this is all we can do:

1. Switch from PHP DSO to SuPHP

2. Globally chmod 640 all PHP/CGI as well as XML files for all users home directories ( home/user/public_html ) as many of our users PHP/CGI/XML files have db config info in them and cherry picking the ones that do/don't would be too tedious)

3. Globally set all other files (images, css, everything else) in public_html to 644 so Apache can still access them..

4. Globally set all directories in all users pub html directories as 755...

I have a few questions though...

1. Regarding #4, can we set directories in pub html to 750 or does it have to be set to 755 for Apache to read all directories?

2. Is there a way to set files/folders outside of public_html in /home/user/* to 640 since they are not used by apache? I noticed cPanel has 777 permissions on some different folders such as mail/ etc... Why is this?

3. How can we prevent users from setting certain files (such as PHP etc) to anything but 640? Can SuPHP be set to automatically correct (eg like a nightly cron) or is there a FTP/SFTP setting that sets default permissions upon file upload by the user?

[sparek-3]

Look at the umask setting for your FTP server and for suPHP. This won't prevent users from applying insecure permissions, but it can help in creating new files with different permissions.